Page MenuHomeFreeBSD

vt: register the memory regions used by the vt drivers
ClosedPublic

Authored by royger on Dec 10 2014, 5:06 PM.
Tags
None
Referenced Files
F80131932: D1291.diff
Thu, Mar 28, 8:19 AM
Unknown Object (File)
Dec 23 2023, 3:16 PM
Unknown Object (File)
Dec 23 2023, 5:58 AM
Unknown Object (File)
Dec 19 2023, 11:41 PM
Unknown Object (File)
Nov 19 2023, 12:34 PM
Unknown Object (File)
Oct 28 2023, 11:17 PM
Unknown Object (File)
Oct 3 2023, 4:39 PM
Unknown Object (File)
Aug 20 2023, 5:14 AM
Subscribers
None

Details

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

royger retitled this revision from to vt: register the memory regions used by the vt drivers.
royger updated this object.
royger edited the test plan for this revision. (Show Details)
royger added reviewers: emaste, 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?

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.

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 added inline comments.
sys/dev/vt/hw/efifb/efifb.c
187 ↗(On Diff #2704)

vt_efifb_identify for consistency with other functions here?

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

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

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

ray edited edge metadata.

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!

This revision is now accepted and ready to land.Dec 19 2014, 1:38 PM
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 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.

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?

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.

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 updated this revision to Diff 2815.

Closed by commit rS276064 (authored by @royger).