Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/22/2010 04:00 PM, Paul Brook wrote:
>> On 03/22/2010 11:16 AM, Paul Brook wrote:
>>      
>>>> But look at the lguest virtio implement.  We would definitely model a
>>>> VirtIOBus if we implemented something like that in qemu.  VirtIO really
>>>> is designed to be a bus.
>>>>          
>>> When you say "bus" you actually mean point-point connection, right[1]?
>>> I don't see anything in virtio that allows arbitration of multiple
>>> devices, or any particular need for one as it can be handled by the host
>>> bus bindings.
>>>        
>> Virtio itself doesn't define any type of bus operations but is designed
>> to let it nicely fit into existing bus infrastructures.
>>      
> My understanding is that virtio specifies transport agnostic queueing API for
> passing buffers of data, and a small device specific config space.  IMO a qemu
> virtio bus should implement exactly that.  The host bridge submits buffers,
> and the device processes them. Allowing more than one device on this bus just
> adds complication for no benefit.  The only reason to have multiple devices on
> a single bus is so that the can arbitrate a shared resource, and in this case
> we have no resources to share.  If a single host device wants to support
> multiple virtio devices then it can create multiple busses.
>
> The purpose of the virtio bus is to expose the isolation between virtio device
> and host bridge/binding to the user. This allows virtio devices to be
> configured consistently without having to duplicate N hosts * M devices.
>    

I think we ultimately agree.  I think your point is that it's not 
technically a bus but it's convenient to model it that way.  I 
definitely understand that point.

Regards,

Anthony Liguori