vt: register the memory regions used by the vt drivers

[royger]

Summary

Current VT drivers don't register the memory regions they use with the
nexus. This patch makes vt_vga, vt_efifb and vt_fb register the memory
regions they use.

This is needed (at least) for Xen support, since the FreeBSD kernel will try
to use the holes in the memory map to map memory from other domains and
setup it's grant table.

Sponsored by: Citrix Systems R&D

[sbruno]

test in progress.

[sbruno]

works a lot better. No disk/lockups detected.

The vnc console I use gets dropped consistently on startup on vtvga initialization which is a regression versus syscons. I think this is a vt(4) regression not a xen regression though. Ed?

[royger]

I'm using Qemu 2.0.2 with Xen and the VNC seems to work as expected, the only difference I notice is that the size of the screen changes upon vt initialization. The client is TigerVNC.

[emaste]

In D1291#5, @royger wrote:

I'm using Qemu 2.0.2 with Xen and the VNC seems to work as expected, the only difference I notice is that the size of the screen changes upon vt initialization. The client is TigerVNC.

The resizing happens because VGA text mode is 720x400 (with 9x16 characters) and the graphics mode vt(4) uses is 640x480 (with 8x16 characters).

@sbruno, what VNC client are you using? I wonder if it does not handle the resolution switch?

[emaste]

sys/dev/vt/hw/efifb/efifb.c

187 ↗

(On Diff #2704)

vt_efifb_identify for consistency with other functions here?

[sbruno]

In D1291#6, @emaste wrote:

In D1291#5, @royger wrote:

I'm using Qemu 2.0.2 with Xen and the VNC seems to work as expected, the only difference I notice is that the size of the screen changes upon vt initialization. The client is TigerVNC.

The resizing happens because VGA text mode is 720x400 (with 9x16 characters) and the graphics mode vt(4) uses is 640x480 (with 8x16 characters).

@sbruno, what VNC client are you using? I wonder if it does not handle the resolution switch?

I'm using the tightvnc port

[emaste]

Michael Dexter tested the branch and ran into a panic: https://twitter.com/michaeldexter/status/545388771168878592

[emaste]

I think you want to remove the vt_fb part of this change

[royger]

Removed the vt_fb part of the change, updated patch also uploaded to:

https://people.freebsd.org/~royger/0001-vt-register-the-memory-regions-used-by-the-vt-driver.patch

[emaste]

Both vt_vga and vt_efifb work in qemu for me with this change.

[ray]

I like it.
Good idea Roger. Thank you for that!

I'm not sure only about panic on bus_alloc_resource.
Possible, resource can be busy (by parent who setup FB), so if resource busy we have not to panic.

Thanks!

[emaste]

In D1291#15, @ray wrote:

Possible, resource can be busy (by parent who setup FB), so if resource busy we have not to panic.

I think we can require the parent setting up the FB to alloc the resource, no?

[ray]

In D1291#18, @emaste wrote:

In D1291#15, @ray wrote:

Possible, resource can be busy (by parent who setup FB), so if resource busy we have not to panic.

I think we can require the parent setting up the FB to alloc the resource, no?

In that case nexus is parent, so parent have no idea what region is set as FB, just can see if it free or busy.

[royger]

I'm not sure I'm following, AFAICT nexus doesn't know anything about the FB, how is it supposed to claim the memory regions?

[ray]

In D1291#20, @royger wrote:

I'm not sure I'm following, AFAICT nexus doesn't know anything about the FB, how is it supposed to claim the memory regions?

If someone make driver for EFI FB :)))
Then that driver have to map existing or create new FB region(regions), then it will be owner. Not nexus. But nexus will know that region already allocated.

[royger]

In D1291#21, @ray wrote:

If someone make driver for EFI FB :)))
Then that driver have to map existing or create new FB region(regions), then it will be owner. Not nexus. But nexus will know that region already allocated.

IMHO I would leave the panic because we don't have such use-case right now, and if something different than the VT FB driver takes over the MMIO region it is certainly going to be an issue worth panicking.

[royger]

Closed by commit rS276064 (authored by @royger).