From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvqyA-0001wi-5K for qemu-devel@nongnu.org; Mon, 30 Jul 2012 10:29:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svqy2-0001ls-3x for qemu-devel@nongnu.org; Mon, 30 Jul 2012 10:29:14 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:63058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svqy1-0001lb-UZ for qemu-devel@nongnu.org; Mon, 30 Jul 2012 10:29:06 -0400 Received: by pbbro12 with SMTP id ro12so9475543pbb.4 for ; Mon, 30 Jul 2012 07:29:04 -0700 (PDT) From: Anthony Liguori In-Reply-To: <5016926E.3090109@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> <501676D7.3010504@redhat.com> <878ve11j70.fsf@codemonkey.ws> <50168C68.9010103@redhat.com> <874nopicrc.fsf@codemonkey.ws> <5016926E.3090109@redhat.com> Date: Mon, 30 Jul 2012 09:29:01 -0500 Message-ID: <87obmx491u.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Avi Kivity Cc: qemu-devel@nongnu.org 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. > 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. > 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. For non-virtio-pci versions of the device, the legacy I/O area would not exist. > so the pc-oriented card will have to be a mix of > virtio and stdvga multiplexed on one pci card (maybe two functions, but > I'd rather avoid that). Yes. We could modify stdvga to expose the VGA ram area as the second bar and make the first bar a virtio-pci compatible area. This would require modifying the VGA bios to understand the change but otherwise, should be compatible. It would take modeling VGACommonState as a proper device and then it's a pretty simple process of embedding a VGACommonState within a virtio-pci device. It should work fairly well. It gets a little complicated in terms of who owns the DisplayState but that's a solvable problem. Regards, Anthony Liguori > > -- > error compiling committee.c: too many arguments to function