From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkGcF-0003hz-IU for qemu-devel@nongnu.org; Sun, 16 Dec 2012 10:59:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkGcD-0002uh-3e for qemu-devel@nongnu.org; Sun, 16 Dec 2012 10:58:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkGcC-0002ud-RG for qemu-devel@nongnu.org; Sun, 16 Dec 2012 10:58:57 -0500 Date: Sun, 16 Dec 2012 18:01:55 +0200 From: "Michael S. Tsirkin" Message-ID: <20121216160155.GB15790@redhat.com> References: <1355157952-2321-1-git-send-email-fred.konrad@greensocs.com> <1355157952-2321-8-git-send-email-fred.konrad@greensocs.com> <50C8C4A2.7010709@suse.de> <50C8C6E9.9050207@redhat.com> <87r4muronh.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r4muronh.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , e.voevodin@samsung.com, rusty@rustcorp.com.au, mark.burton@greensocs.com, qemu-devel@nongnu.org, Alexander Graf , stefanha@redhat.com, cornelia.huck@de.ibm.com, Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= , fred.konrad@greensocs.com On Thu, Dec 13, 2012 at 08:51:30AM -0600, Anthony Liguori wrote: > Paolo Bonzini writes: > > > Il 12/12/2012 18:58, Peter Maydell ha scritto: > >> It should be equally > >> valid to just use the PCI transport plugged into a VirtioDevice, > >> both of which were created by the user with -device [and for > >> new transports, separate transport and backend should be the > >> standard]. That means the virtio-bus interface needs a way for > >> the backend to announce to the transport what it is so that > >> the PCI transport can set the right PCI IDs. > > > > There is such an interface (the device_id, aka VIRTIO_ID_*). Then > > virtio-pci needs a mapping from the device_id to the (default) > > vendor_id/device_id/class tuple. > > Why? > > I think it's perfectly fine to have to specify a device ID for > virtio-pci. > > The way virtio-pci is designed is such that every device that uses > virtio-pci ends up looking like an independent PCI device. > > We should always have virtio-blk-pci, virtio-net-pci, etc. The goal of > this refactoring should not be to eliminate that. > > But these devices should be trivial to implement and modelled in a sane > way. > > I don't think we should be trying to solve the problem of making > virtio-pci "easy to use". Why would you say: > > -device virtio-pci,id=foo -device virtio-blk,bus=foo > > When you can just say: > > -device virtio-pci-blk > > I think we're optimizing for the wrong thing here... > > Regards, > > Anthony Liguori > > > > > Paolo I agree. What I mean is this: virtio has device IDs. These are not pci specific and are defined in linux/virtio_ids.h Now it looks like pci device IDs of virtio devices are pci id = 0x1000 + virtio device ID; so let's pull virtio_ids.h from linux and write a macro that does + 0x1000 instead of hard-coding values. Makes sense? -- MST