From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SycNj-0005Fu-2Z for qemu-devel@nongnu.org; Tue, 07 Aug 2012 01:31:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SycNh-0005Hx-Rf for qemu-devel@nongnu.org; Tue, 07 Aug 2012 01:31:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SycNh-0005Ht-JX for qemu-devel@nongnu.org; Tue, 07 Aug 2012 01:31:01 -0400 Message-ID: <5020A800.9010902@redhat.com> Date: Tue, 07 Aug 2012 07:30:40 +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> <501FC480.8060707@redhat.com> <1344287768.24037.107.camel@pasglop> In-Reply-To: <1344287768.24037.107.camel@pasglop> Content-Type: text/plain; charset=UTF-8 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: Benjamin Herrenschmidt Cc: Avi Kivity , Anthony Liguori , qemu-devel@nongnu.org On 08/06/12 23:16, Benjamin Herrenschmidt wrote: > On Mon, 2012-08-06 at 15:20 +0200, Gerd Hoffmann wrote: >> There are discussions about re-doing the guest/host interface (command >> rings etc) now and then, by adding a qxl2 device (or maybe even extend >> stdvga), dropping a bunch of backward compatibility stuff in qxl.c. >> >> Sending the spice commands over virtio is certainly an option here. >> I'm >> not sure it is possible to drive virtio rings from userspace (Xorg >> driver), but that issue should go away with the qxl kms driver in the >> works. > > Anything that gets rid of the qxl memory region API is welcome ;-) Some > of that stuff is really gross. Well, it is needed for sanity checking memory references (to images etc) in qxl commands, so we can't just zap it. But having a kms driver in kernel space makes things easier again: You could simply register a single memory region for the guest ram, then basically use guest physical addresses for qxl memory references. qxl commands & data can live in guest ram and you can stick references to the commands into virtio rings ... cheers, Gerd