Re: [Qemu-devel] Virtio-pci issue
On Tue, May 29, 2012 at 4:48 AM, Evgeny Voevodin e.voevo...@samsung.com wrote: On 28.05.2012 16:37, Stefan Hajnoczi wrote: On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodine.voevo...@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 Ok, I'll try ) As I see, to connect a pci device to board it should be enough to specify -device ... on command line. And in the way virtio refactoring is moving, board should create transport pci device to correspond each back-end created by -device ... command. So, if we create more back-ends with -device option then transports created by board then there would be back-ends that will not have corresponding transport device. As result user should know maximum number of transport instances created by board to not overrun it. In the case of mmio I think it's normal, but not in the pci case. Am I right? The only limit to PCI devices should be the number slots available. For convenience we could continue to have virtio-blk-pci, virtio-net-pci, etc which actually just add a virtio-pci adapter and link it to a virtio device. Users that want full control can specify: -device virtio-pci,id=virtio-pci.0 -device virtio-blk,transport=virtio-pci.0,... The board doesn't need to preallocate virtio-pci adapters. Stefan
Re: [Qemu-devel] Virtio-pci issue
On 30.05.2012 11:56, Stefan Hajnoczi wrote: On Tue, May 29, 2012 at 4:48 AM, Evgeny Voevodine.voevo...@samsung.com wrote: On 28.05.2012 16:37, Stefan Hajnoczi wrote: On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodine.voevo...@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 Ok, I'll try ) As I see, to connect a pci device to board it should be enough to specify -device ... on command line. And in the way virtio refactoring is moving, board should create transport pci device to correspond each back-end created by -device ... command. So, if we create more back-ends with -device option then transports created by board then there would be back-ends that will not have corresponding transport device. As result user should know maximum number of transport instances created by board to not overrun it. In the case of mmio I think it's normal, but not in the pci case. Am I right? The only limit to PCI devices should be the number slots available. Where number of slots is defined? For convenience we could continue to have virtio-blk-pci, virtio-net-pci, etc which actually just add a virtio-pci adapter and link it to a virtio device. Users that want full control can specify: -device virtio-pci,id=virtio-pci.0 -device virtio-blk,transport=virtio-pci.0,... The board doesn't need to preallocate virtio-pci adapters. Stefan You suggest transport device to be created by user... In that case an interface would differ from mmio since in the case of mmio a board should specify memory and irq mappings for transport device. -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] Virtio-pci issue
On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodin e.voevo...@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
Re: [Qemu-devel] Virtio-pci issue
On 28.05.2012 16:37, Stefan Hajnoczi wrote: On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodine.voevo...@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 Ok, I'll try ) As I see, to connect a pci device to board it should be enough to specify -device ... on command line. And in the way virtio refactoring is moving, board should create transport pci device to correspond each back-end created by -device ... command. So, if we create more back-ends with -device option then transports created by board then there would be back-ends that will not have corresponding transport device. As result user should know maximum number of transport instances created by board to not overrun it. In the case of mmio I think it's normal, but not in the pci case. Am I right? -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] Virtio-pci issue
On Thu, May 10, 2012 at 12:24 PM, Evgeny Voevodin e.voevo...@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
On 23.05.2012 17:36, Stefan Hajnoczi wrote: On Thu, May 10, 2012 at 12:24 PM, Evgeny Voevodin e.voevo...@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 RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
[Qemu-devel] Virtio-pci issue
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 RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
