Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out

[Benjamin Herrenschmidt]

On Tue, 2012-07-31 at 09:17 +0930, Rusty Russell wrote:
> 
> Shared memory is an efficiency thing, not a requirement.  If the
> virtio
> side-channel tells the device about the location of framebuffer
> changes, it could still be quite efficient.

But potentially tricky to get things like BIOSes working etc... you want
to keep basic access simple.

At this point, I'm hesitating between those two models:

1- Keep qemu-vga and hack virtio to have the virtio BAR not be BAR 0
(BAR 3 in my current code) and be an optional feature (you can get basic
qemu-vga without virtio if you disable CONFIG_VIRTIO for example, you
just don't get acceleration). It's still a PCI device and mode setting
is done via either legacy PIO or MMIO registers, so it's not necessarily
s390 friendly, though at least the MMIO registers are BAR mapped.

The advantage is that it's compatible with the existing qemu PCI VGA,
however it makes it harder to "Fix" the vendor ID, among other cons.

2- Create a -new- virtio-vga (ie, leave vga-std alone and eventually
deprecate it). This is basically a virtio-pci base with the virtio BAR
as BAR 0 (so compatible with overall virtio) and we get a proper virtio
vendor/device. However, I do add a second BAR for the linear framebuffer
and it supports optionally legacy IO ports for mode setting.

For non-legacy mode setting, I either keep another MMIO BAR for doing a
BAR-variant of the legacy IO ports or provide a simple virtio packet
format that can be used to populate the VGA/VBE registers & palette.

Finally, I adapt the vbios so that VBE & co still works, including text
mode.

The latter sounds like a better long term approach, however it lacks
backward compat with qemu-vga, but I doubt it's a big deal especially if
we provide a working VBE ROM for x86.

Cheers,
Ben.