qemu-devel
[Top][All Lists]
Advanced

[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: Fri, 3 Aug 2012 08:45:32 +0200
User-agent: Mutt/1.5.21 (2011-07-01)

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?

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]