[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other o
From: |
Alon Levy |
Subject: |
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out |
Date: |
Tue, 7 Aug 2012 09:00:55 +0200 |
User-agent: |
Mutt/1.5.21 (2011-07-01) |
On Fri, Aug 03, 2012 at 08:41:36AM -0500, Anthony Liguori wrote:
> Alon Levy <address@hidden> writes:
>
> > On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote:
> >> Andreas Färber <address@hidden> 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
> >>
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Avi Kivity, 2012/08/01
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Alon Levy, 2012/08/03
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/08/03
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out,
Alon Levy <=
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Gerd Hoffmann, 2012/08/07
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Erlon Cruz, 2012/08/07
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Gerd Hoffmann, 2012/08/07
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Erlon Cruz, 2012/08/07
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Gerd Hoffmann, 2012/08/08
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Erlon Cruz, 2012/08/08
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Gerd Hoffmann, 2012/08/09
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Andreas Färber, 2012/08/01
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Gerd Hoffmann, 2012/08/06
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Gerd Hoffmann, 2012/08/06