From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sydmw-0000Eo-34 for qemu-devel@nongnu.org; Tue, 07 Aug 2012 03:01:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sydmr-0006mK-KX for qemu-devel@nongnu.org; Tue, 07 Aug 2012 03:01:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sydmr-0006m8-Cb for qemu-devel@nongnu.org; Tue, 07 Aug 2012 03:01:05 -0400 Date: Tue, 7 Aug 2012 09:00:55 +0200 From: Alon Levy Message-ID: <20120807070055.GA25376@garlic.redhat.com> References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com> <1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com> <1343649267.21647.44.camel@pasglop> <20120730161954.GM29361@garlic.redhat.com> <50194E79.5090409@suse.de> <8739465sea.fsf@codemonkey.ws> <20120803064532.GR29361@garlic.redhat.com> <87boism6sv.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87boism6sv.fsf@codemonkey.ws> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= , Avi Kivity On Fri, Aug 03, 2012 at 08:41:36AM -0500, Anthony Liguori wrote: > Alon Levy writes: >=20 > > On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote: > >> Andreas F=E4rber writes: > >>=20 > >> > 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. [...] > >> >>=20 > >> >> I would love to hear something more specific about this. I assume= you > >> >> are talking about libspice-server and not the device itself, sinc= e the > >> >> device itself has nothing specifically matching windows. > >> > > >> > I can't comment on what Ben meant, but from my perspective the rea= lly > >> > awful thing about SPICE was its huge tree of dependencies, includi= ng a > >> > very specific version of celt that we now need to package and main= tain > >> > specifically for SPICE. At least during the big QOM refactorings. > >>=20 > >> Ack. > >>=20 > >> This is why I've been advocating for a new PV device model that can > >> negotiation in full SPICE support. > >>=20 > >> Then we could keep libspice an optional dependency, but move all gue= sts > >> 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 a= lso > > a virtio device and a guest driver will recognize this by poking some= io > > ports or looking at another pci field? >=20 > 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,=20 > move the vram bar from 0->1 and update the VGA BIOS accordingly, it Jus= t > Works. Sounds good. >=20 > With no feature bits negotiated, this is all you get--a plain VESA > compatible interface. >=20 > 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. >=20 > 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. >=20 > 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. >=20 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). >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 libspic= e > isn't present). >=20 > Regards, >=20 > Anthony Liguori >=20 > > > >>=20 > >> Regards, > >>=20 > >> Anthony Liguori > >>=20 > >> > > >> > Elsewhere QEMU is built around the principle of opting individual > >> > features in rather than requiring a whole bunch of stuff just to d= o a > >> > basic qxl compile test for patches. > >> > > >> > Andreas > >> > > >> > --=20 > >> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > >> > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N= =FCrnberg > >>=20