From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyNeU-0005sk-5m for qemu-devel@nongnu.org; Mon, 06 Aug 2012 09:47:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyNeO-0001Wp-8T for qemu-devel@nongnu.org; Mon, 06 Aug 2012 09:47:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyNeO-0001Wh-0D for qemu-devel@nongnu.org; Mon, 06 Aug 2012 09:47:16 -0400 Message-ID: <501FCADE.9080006@redhat.com> Date: Mon, 06 Aug 2012 15:47:10 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com> <1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com> <1343649267.21647.44.camel@pasglop> <501676D7.3010504@redhat.com> <878ve11j70.fsf@codemonkey.ws> <50168C68.9010103@redhat.com> <874nopicrc.fsf@codemonkey.ws> <5016926E.3090109@redhat.com> <87obmx491u.fsf@codemonkey.ws> <50169BD5.6060807@redhat.com> <87ipd5xmpb.fsf@codemonkey.ws> In-Reply-To: <87ipd5xmpb.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Rusty Russell , Avi Kivity , qemu-devel@nongnu.org Hi, > QXL has a lot of short comings. Here's a short list: > > - It's 100% PC centric. It requires PCI and is completely oblivious to > endianness. No. The endianess is actually clearly defined. It's little endian for both guest/host interface (aka qxl) and the network protocol. So it is "only" the libspice code which needs fixing. Should be not as bad as it sounds. There is a code generator for writing/parsing the network protocol, winding up native endian <=> little endian handling there shouldn't be that hard. Likewise there is a piece of code translating qxl device structs into internal spice-server structs (applying sanity checks along the way). There we can hook up the byteswapping for the guest/host interface. > - It's all-or-nothing with respect to Spice support. libspice is a big > external dependency. It cannot be mandated as a QEMU requirement > because it's not portable enough. This means we can never make qxl > the default device because we can't guarantee it's there. Indeed. > But there's a lot of value in a new graphics interface that uses virtio > and negotiates support for the Spice protocol. That way, if QEMU > doesn't have Spice support, the feature won't be exposed to the guest > and you can still have a legacy VGA interface. What does it buy us? Even with -vga std-which-might-have-spice-over-virtio-support you still have to figure whenever qemu has spice support and pass / don't pass -spice $opts accordingly. > Then we can change the default. Basic 2d commands (like blit and solid > fill) can be done without going through libspice. We can create a set of basic 2d accel commands and implement them in both stdvga and qxl, where qxl would translate them into spice ops of course. > Then we can stop messing around with having multiple display types. > It would be a huge usability improvement and would allow us to focus on > a single graphics adapter for all architectures. Improving stdvga to support basic 2d accel isn't that much effort. I think it is worth doing it, even when it is obsoleted by a redesigned / rewritten qxl2 some day. cheers, Gerd