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

[Anthony Liguori <anthony@codemonkey.ws>]

Alon Levy <alevy@redhat.com> writes:

> On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote:
>> Andreas Färber <afaerber@suse.de> writes:
>> 
>> > Am 30.07.2012 18:19, schrieb Alon Levy:
>> >> On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
>> >>> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
>> >>>
>> >>>> [...] why not go all the way to qxl?
>> >>>>
>> >>>> That will give you better graphics performance with no need to hack.
>> >>>
>> >>> Well, qxl is pretty awful from what I can see so far. [...]
>> >> 
>> >> I would love to hear something more specific about this. I assume you
>> >> are talking about libspice-server and not the device itself, since the
>> >> device itself has nothing specifically matching windows.
>> >
>> > I can't comment on what Ben meant, but from my perspective the really
>> > awful thing about SPICE was its huge tree of dependencies, including a
>> > very specific version of celt that we now need to package and maintain
>> > specifically for SPICE. At least during the big QOM refactorings.
>> 
>> Ack.
>> 
>> This is why I've been advocating for a new PV device model that can
>> negotiation in full SPICE support.
>> 
>> Then we could keep libspice an optional dependency, but move all guests
>> to use a single graphics driver.  Likewise, management tools wouldn't
>> need to worry about multiple types of graphics cards.
>
> This sounds great, but how would that negotiation work? Do you intend
> for a VGA device (i.e. pci vendor & product id's of cirrus) that is also
> a virtio device and a guest driver will recognize this by poking some io
> ports or looking at another pci field?

It would be an VGA/SVGA/VESA/VBE compatible virtio-pci device.  If we
take virtio-pci, do vga_init_common, set the class codes correctly, 
move the vram bar from 0->1 and update the VGA BIOS accordingly, it Just
Works.

With no feature bits negotiated, this is all you get--a plain VESA
compatible interface.

We would then add feature bits to allow you to do basic operations like
setting display mode, damage update, and perhaps some 2d acceleration
like blit.  This all happens through messages on a virtqueue.

While this is totally virtio-pci ABI compatible, we'll need to enhance
the virtio API within Linux to allow the notion of "map large memory
region."  It's not entirely clear to me yet how to do this only because
non-PCI transports probably need this memory to be guest allocated.
It's possible that we could add another vring type abstraction layer to
handle this difference.

Anyway, we would then add additional feature bits to things like Spice.
It's not clear to me yet how this would work in detail (I don't know
enough about Spice).  The easiest thing to do is simply introduce a
dedicated virtqueue for Spice and speak exactly the same protocol that
QXL does today.

The trouble with that though is that some of the things in QXL today
probably overlap with features we want if libspice is not available
(like mode setting).

So if it's reasonable, it would be best to negotiate in Spice
feature-by-feature using Spice command format where it makes sense and
something more generic where it makes sense.

QEMU would have to fully decode these commands and hand off the results
to libspice if it was there.

So in QEMU, if libspice is present, QEMU would decode all commands and
hand them to libspice in a form it understands (this may require some
hopefully trivial mapping for things like mode setting).  If libspice
isn't present, QEMU only exposes the features it can handle on its own.

This should give us the best of all worlds.  A legacy VGA compatible
interface that speaks virtio, works on non-PCI architectures, and has
the full capabilities of Spice (with the ability to fallback if libspice
isn't present).

Regards,

Anthony Liguori

>
>> 
>> Regards,
>> 
>> Anthony Liguori
>> 
>> >
>> > Elsewhere QEMU is built around the principle of opting individual
>> > features in rather than requiring a whole bunch of stuff just to do a
>> > basic qxl compile test for patches.
>> >
>> > Andreas
>> >
>> > -- 
>> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>>