[Qemu-devel] Virtio-pci issue

[Qemu-devel] Virtio-pci issue

[Evgeny Voevodin]

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?

-- 
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow R&D center, Samsung Electronics
e-mail: e.voevodin@samsung.com

Re: [Qemu-devel] Virtio-pci issue

[Stefan Hajnoczi]

On Thu, May 10, 2012 at 12:24 PM, Evgeny Voevodin
<e.voevodin@samsung.com> 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

Re: [Qemu-devel] Virtio-pci issue

[Evgeny Voevodin]

On 23.05.2012 17:36, Stefan Hajnoczi wrote:
> On Thu, May 10, 2012 at 12:24 PM, Evgeny Voevodin
> <e.voevodin@samsung.com>  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

Re: [Qemu-devel] Virtio-pci issue

[Stefan Hajnoczi]

On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodin <e.voevodin@samsung.com> wrote:
> 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.

Not sure I understand the problem.  Can you rephrase it?

Stefan