From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svr4y-0005cH-Tc for qemu-devel@nongnu.org; Mon, 30 Jul 2012 10:36:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svr4u-0004vM-QH for qemu-devel@nongnu.org; Mon, 30 Jul 2012 10:36:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svr4u-0004uh-Gm for qemu-devel@nongnu.org; Mon, 30 Jul 2012 10:36:12 -0400 Message-ID: <50169BD5.6060807@redhat.com> Date: Mon, 30 Jul 2012 17:36:05 +0300 From: Avi Kivity 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> In-Reply-To: <87obmx491u.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: qemu-devel@nongnu.org On 07/30/2012 05:29 PM, Anthony Liguori wrote: > Avi Kivity writes: > >>>> Virtio makes sense for qxl, but for now we have the original pci model >>>> which I don't see a reason why it can't work for ppc. >>> >>> I'm sure it can work for PPC given enough effort. But I think the >>> question becomes, why not invest that effort in moving qxl to the >>> standard transport that the rest of our PV devices use. >> >> The drm drivers for the current model are needed anyway; so moving to >> virtio is extra effort, not an alternative. > > This is just a point in time statement. If we were serious about using > virtio then we could quickly introduce a virtio transport and only > target the DRM drivers at the virtio transport. That doesn't help all the deployed hypervisors out there. IMO we're mature enough, and the difference doesn't warrant a new interface. >> Note virtio doesn't support mapping framebuffers yet > > Yes. I haven't seen a good proposal yet on how to handle this. I think > this is the main problem to solve. It doesn't seem to be such a huge problem, though it does turn virtio into a respec'ed PCI. > >> or the entire vga compatibility stuff > > This is actually independent of virtio. A virtio-pci device could > expose it's class code as a VGA adapter and also handle I/O accesses for > the legacy region. This is strictly a PC-ism. We have to share the BAR space with VGA; not a huge problem. -- error compiling committee.c: too many arguments to function