[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Virtio-pci issue

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Virtio-pci issue
Date: Wed, 30 May 2012 08:56:11 +0100

On Tue, May 29, 2012 at 4:48 AM, Evgeny Voevodin <address@hidden> wrote:
> On 28.05.2012 16:37, Stefan Hajnoczi wrote:
>> On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodin<address@hidden>
>>  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]