From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MadSd-0003Jv-1P for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:35:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MadSX-0003GS-Fu for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:35:21 -0400 Received: from [199.232.76.173] (port=45856 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MadSX-0003GP-BZ for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:35:17 -0400 Received: from qw-out-1920.google.com ([74.125.92.145]:31002) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MadSW-0006bS-Vu for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:35:17 -0400 Received: by qw-out-1920.google.com with SMTP id 5so1166803qwc.4 for ; Mon, 10 Aug 2009 15:35:16 -0700 (PDT) Message-ID: <4A80A0A1.2020905@codemonkey.ws> Date: Mon, 10 Aug 2009 17:35:13 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function References: <20090810192809.GA16800@redhat.com> <4A8076F0.5050700@codemonkey.ws> <20090810194753.GA16803@redhat.com> <4A808437.8040307@codemonkey.ws> <20090810221940.GB17099@redhat.com> In-Reply-To: <20090810221940.GB17099@redhat.com> 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: "Michael S. Tsirkin" Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org Michael S. Tsirkin wrote: > On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote: > >> There ought to be a way to layer qdev properties that achieves this goal >> so that when you create a virtio-pci-block device, you have the ability >> to turn off indirect sg without virtio-block having to know what that is. >> > > I don't understand, sorry. Why do you insist on involving pci here? > ring layout has nothing to do with pci, does it? What I'm saying is that virtio-blk-pci, which is the qdev instantiation of virtio-pci + virtio-blk, should be able to have a set of qdev properties that is composed of a combination of at least two sets of properties: virtio-blk's qdev properties and virtio-pci's qdev properties. Right now, all of the properties are defined in virtio-pci.c, so you could add a property that was DEFINE_PROP_BOOL("indirect-sg", ...), that you could then use to selectively enable/disable indirect sg on virtio-blk-pci devices without ever having to involve virtio-blk.c. Ideally, we wouldn't have the properties centralized in virtio-pci.c. Rather, it would be nice if virtio-blk.c could have a set of properties and virtio-pci.c could just add those properties to it's own set of properties. Today, we don't have a concept of a ring abstraction. If we did, then virtio-ring.c could have it's own set of properties. N.B. I expect that the in-kernel virtio-net device is going to be separate qdev device than virtio-net-pci. It can have an identical guest interface but within qemu, it should be a separate device. This is how we handle the in-kernel PIT and it's how we should handle the in-kernel APIC. Regards, Anthony Liguori