On Fri, Aug 03, 2012 at 08:41:36AM -0500, Anthony Liguori wrote: > Alon Levy <al...@redhat.com> writes: > > > On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote: > >> Andreas Färber <afaer...@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 > >>
