From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [PATCH] Add VirtIO Frame Buffer Support Date: Wed, 04 Nov 2009 10:35:42 -0600 Message-ID: <4AF1AD5E.5040205@codemonkey.ws> References: <1257199759-2941-1-git-send-email-agraf@suse.de> <4AEFCBED.50804@redhat.com> <4AEFCCBA.9050408@redhat.com> <8BA1853F-11C9-44B1-9FDB-1DFDAED40E1B@suse.de> <4AEFCEDA.4030308@redhat.com> <87F51670-CB3F-431C-87B4-A8746F996C6F@suse.de> <20091103112543.GA24834@snarc.org> <4AEFFA0A.4040105@redhat.com> <20091104160931.GA3647@snarc.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091104160931.GA3647@snarc.org> Sender: kvm-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Vincent Hanquez Cc: Avi Kivity , linux-fbdev-devel@lists.sourceforge.net, Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org Vincent Hanquez wrote: > On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote: > >> On 11/03/2009 01:25 PM, Vincent Hanquez wrote: >> >>> not sure if i'm missing the point here, but couldn't it be hypothetically >>> extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't >>> imagine the cirrus or stdvga driver be able to do that ever ;) >>> >>> >> cirrus has pretty good 2d acceleration. 3D is a mega-project though. >> > > absolutely huge indeed, but still alexander's code is pretty much the > only way, to start such a project. with maybe added benefits on more > and easier 2d acceleration. > > or otherwise wait for SR-IOV graphics cards (or similar tech)... > I think the real question is do we paravirtualize a VGA device or a framebuffer. Obviously, the advantage of doing a framebuffer is that it works for s390. A VGA device has better backwards compatibility on PCs although it's obviously more complex. In an ideal world, we could expose the virtio framebuffer device as part of PCI device that was also VGA capable (virtio-pci-vga transport?). But then there's QXL on the horizon which complicates matters further. I'd say that virtio-fb should just focus on the s390 use case for now. Let things evolve as needed. Regards, Anthony Liguori From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5ips-0006dv-SI for qemu-devel@nongnu.org; Wed, 04 Nov 2009 11:35:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5ipo-0006aj-4p for qemu-devel@nongnu.org; Wed, 04 Nov 2009 11:35:52 -0500 Received: from [199.232.76.173] (port=51616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5ipo-0006ad-0A for qemu-devel@nongnu.org; Wed, 04 Nov 2009 11:35:48 -0500 Received: from mail-pw0-f43.google.com ([209.85.160.43]:55665) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N5ipn-0004ku-F1 for qemu-devel@nongnu.org; Wed, 04 Nov 2009 11:35:47 -0500 Received: by pwi18 with SMTP id 18so25181pwi.2 for ; Wed, 04 Nov 2009 08:35:46 -0800 (PST) Message-ID: <4AF1AD5E.5040205@codemonkey.ws> Date: Wed, 04 Nov 2009 10:35:42 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Add VirtIO Frame Buffer Support References: <1257199759-2941-1-git-send-email-agraf@suse.de> <4AEFCBED.50804@redhat.com> <4AEFCCBA.9050408@redhat.com> <8BA1853F-11C9-44B1-9FDB-1DFDAED40E1B@suse.de> <4AEFCEDA.4030308@redhat.com> <87F51670-CB3F-431C-87B4-A8746F996C6F@suse.de> <20091103112543.GA24834@snarc.org> <4AEFFA0A.4040105@redhat.com> <20091104160931.GA3647@snarc.org> In-Reply-To: <20091104160931.GA3647@snarc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vincent Hanquez Cc: qemu-devel@nongnu.org, linux-fbdev-devel@lists.sourceforge.net, Avi Kivity , kvm@vger.kernel.org, Alexander Graf Vincent Hanquez wrote: > On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote: > >> On 11/03/2009 01:25 PM, Vincent Hanquez wrote: >> >>> not sure if i'm missing the point here, but couldn't it be hypothetically >>> extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't >>> imagine the cirrus or stdvga driver be able to do that ever ;) >>> >>> >> cirrus has pretty good 2d acceleration. 3D is a mega-project though. >> > > absolutely huge indeed, but still alexander's code is pretty much the > only way, to start such a project. with maybe added benefits on more > and easier 2d acceleration. > > or otherwise wait for SR-IOV graphics cards (or similar tech)... > I think the real question is do we paravirtualize a VGA device or a framebuffer. Obviously, the advantage of doing a framebuffer is that it works for s390. A VGA device has better backwards compatibility on PCs although it's obviously more complex. In an ideal world, we could expose the virtio framebuffer device as part of PCI device that was also VGA capable (virtio-pci-vga transport?). But then there's QXL on the horizon which complicates matters further. I'd say that virtio-fb should just focus on the s390 use case for now. Let things evolve as needed. Regards, Anthony Liguori