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 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 >> > > 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
