From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjA8n-0000z4-2K for qemu-devel@nongnu.org; Thu, 13 Dec 2012 09:52:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjA8b-0000qa-6t for qemu-devel@nongnu.org; Thu, 13 Dec 2012 09:52:00 -0500 Received: from e7.ny.us.ibm.com ([32.97.182.137]:35109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjA8b-0000qH-2e for qemu-devel@nongnu.org; Thu, 13 Dec 2012 09:51:49 -0500 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Dec 2012 09:51:47 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 6AC3238C803F for ; Thu, 13 Dec 2012 09:51:45 -0500 (EST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBDEpeC4322570 for ; Thu, 13 Dec 2012 09:51:42 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBDErf5u022937 for ; Thu, 13 Dec 2012 07:53:41 -0700 From: Anthony Liguori In-Reply-To: <50C8C6E9.9050207@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> Date: Thu, 13 Dec 2012 08:51:30 -0600 Message-ID: <87r4muronh.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 , Peter Maydell Cc: e.voevodin@samsung.com, "Michael S. Tsirkin" , mark.burton@greensocs.com, qemu-devel@nongnu.org, Alexander Graf , stefanha@redhat.com, cornelia.huck@de.ibm.com, Andreas =?utf-8?Q?F=C3=A4rber?= , fred.konrad@greensocs.com 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