From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Titi5-0002P7-Pj for qemu-devel@nongnu.org; Wed, 12 Dec 2012 16:19:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tithy-0003wA-Cy for qemu-devel@nongnu.org; Wed, 12 Dec 2012 16:19:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tithy-0003w4-56 for qemu-devel@nongnu.org; Wed, 12 Dec 2012 16:19:14 -0500 Date: Wed, 12 Dec 2012 23:22:17 +0200 From: "Michael S. Tsirkin" Message-ID: <20121212212217.GB23087@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C8C6E9.9050207@redhat.com> 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: Paolo Bonzini Cc: Peter Maydell , aliguori@us.ibm.com, e.voevodin@samsung.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, Alexander Graf , stefanha@redhat.com, cornelia.huck@de.ibm.com, Andreas =?iso-8859-1?Q?F=E4rber?= , fred.konrad@greensocs.com On Wed, Dec 12, 2012 at 07:03:21PM +0100, Paolo Bonzini wrote: > 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. > > Paolo At least device id and vedor id are easy.