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.