From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXOZa-0000oE-9U for qemu-devel@nongnu.org; Wed, 23 May 2012 23:18:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXOZX-0001Co-CL for qemu-devel@nongnu.org; Wed, 23 May 2012 23:18:45 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:39891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXOZX-0001BB-7D for qemu-devel@nongnu.org; Wed, 23 May 2012 23:18:43 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from eusync1.samsung.com ([210.118.77.14]) by mailout4.w1.samsung.com (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTP id <0M4I00ER4BVEJV70@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Thu, 24 May 2012 04:18:50 +0100 (BST) Received: from [106.109.9.191] by eusync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0M4I008V7BUZ0D10@eusync1.samsung.com> for qemu-devel@nongnu.org; Thu, 24 May 2012 04:18:36 +0100 (BST) Message-id: <4FBDA889.4000907@samsung.com> Date: Thu, 24 May 2012 07:18:33 +0400 From: Evgeny Voevodin References: <4FABA585.8050400@samsung.com> In-reply-to: Subject: Re: [Qemu-devel] Virtio-pci issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Peter Maydell , Kyungmin Park , Dmitry Solodkiy , qemu-devel@nongnu.org, Anthony Liguori On 23.05.2012 17:36, Stefan Hajnoczi wrote: > On Thu, May 10, 2012 at 12:24 PM, Evgeny Voevodin > wrote: >> Hi, guys! >> >> While trying to refactor virtio-pci as continuation of my RFC >> virtio-mmio patch series: >> http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03665.html >> I've faced a problem. >> >> I try to create virtio-pci-transport device to which virtio-blk,net,etc >> could be connected. Any board could create as many transport devices as >> it wants and then any actual back-end could be connected to that >> transport through a provided virtio-pci.x bus. virtio-pci-transport is >> derived from TYPE_PCI_DEVICE. >> The problem is that if I create transport devices and wish to connect >> back-ends to them, each back-end would set its properties to the class, >> not to the object. >> For example, vendor_id property is different for blk and net, but since >> they are both have same class PCIDeviceClass, they share that property. >> >> How to deal with this? > I think you are asking how a virtio-pci adapter can have device_id > value that depends on its VirtioDevice (not known at compile-time and > different between virtio-pci adapters). > > You should be able to set the PCI device ID at runtime: > > pci_config_set_device_id(pci_dev->config, device_id_from_virtio_device); > > Take a look at hw/pci.c:pci_qdev_init(). The order of operations is important: > > 1. do_pci_register_device() sets up default values from PCIDeviceClass. > 2. ->init(pci_dev) gets called, this is where your init code gets executed. > > So it should be fine to set the PCI device ID at runtime from > VirtioPCIAdapter::init(). > > Stefan > Oh, thanks a lot, Stefan! As soon as I have a time to continue refactoring, I'll check this functionality. And also there is another problem that I've faced with. It is the ability to plug as many pci back-ends as board wants. I mean that if for each back-end board should create a transport, then user have to know maximum number of transport instances created by board. In the case of mmio transport I think that it's a correct behaviour, but for pci transport seems not. -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow R&D center, Samsung Electronics e-mail: e.voevodin@samsung.com