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

[Alon Levy <alevy@redhat.com>]

On Fri, Aug 03, 2012 at 08:41:36AM -0500, Anthony Liguori wrote:
> 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.

Sounds good.

> 
> 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.
> 

Sounds right.

> 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.

Why not make libspice mandatory? fix it to be big endian compatible
(it's already 32 bit LE compatible). I think this can be done either via
git submodules (either just for spice-protocol or for spice) or
continuing to use it as an external dependency.

Any guest without a qxl-virtio driver would work with the VGA/VBE
device, so we can port the driver gradually to all guests.

> 
> 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
> >>