From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiqVC-0006Z6-Pk for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:54:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiqV6-0005A9-QH for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:53:50 -0500 Received: from cantor2.suse.de ([195.135.220.15]:49252 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiqV6-0005A0-GC for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:53:44 -0500 Message-ID: <50C8C4A2.7010709@suse.de> Date: Wed, 12 Dec 2012 18:53:38 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1355157952-2321-1-git-send-email-fred.konrad@greensocs.com> <1355157952-2321-8-git-send-email-fred.konrad@greensocs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Peter Maydell Cc: aliguori@us.ibm.com, 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, Paolo Bonzini , fred.konrad@greensocs.com Am 12.12.2012 15:25, schrieb Peter Maydell: > How will the PCI transport's PCI vendor/device/class IDs be > set (a) when a virtio-blk backend is created and separately > plugged into a virtio-pci transport (b) for the legacy > virtio-pci-blk? [ideally the answer to (b) should be "in the > same way as for (a)"] The obvious answer would be that PCI properties need to be set on the PCI device, not an a VirtioDevice sitting on a virtio-bus. I.e., with the proposed refactoring we'd have on the virtio-bus: - VirtioDevice + VirtioBlockDevice + VirtioSCSIDevice - has-a scsi-bus ... In turn that means that every VirtioDevice to be exposed as PCI device to the guest needs it own PCIDevice exposing a private virtio-bus. - PCIDevice - VirtioPCIDevice - has-a virtio-bus + virtio-blk-pci - has-a VirtioBlockDevice on its virtio-bus + virtio-scsi-pci - has-a VirtioSCSIDevice on its virtio-bus ... This also happens to solve most of the migration compatibility pretty nicely because the wapping PCI devices would be used almost as before, some state may need to be forwarded to the VirtioDevice. Finally supplying a public device_initialize() or so would be helpful for the latter since VMState cannot cross pointers IIRC. I'll look into that part since inlining the old qdev functions cripples my Tegra work. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg