qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paul Brook
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Mon, 22 Mar 2010 21:00:59 +0000
User-agent: KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; )

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

> If you look at something like lguest, instead of piggying backing on
> another bus, it introduces a bus as part of it's virtio infrastructure.
> It's basically a shared memory page in a well known location.
> 
> Anyway, if you were to implement virtio-lguest in qemu, it would have to
> be a bus.  Likewise, the virtio-s390 implement would also have to be a bus.

I'm not convinced. AFAIKS the s390-virtio bus is just like any other 
peripheral bus. The only difference is that s390-virtio is something we 
invented, whereas PCI matches the programming interface used by real hardware.
You may have a single cpu to s390-virtio bridge, and multiple s390-virtio to 
virtio bridges, but you still only need a single virtio device attached to 
each of those.

By the same token, a virtio bus is not/need not be hot-pluggable. The 
(PCI/s390/whatever)-to-virtio bridge may be hot pluggable. This will cause 
virtio busses to appear and be destroyed. However this can happen atomically, 
so we will never need to add/remove a virtio device from an active bus.

Paul




reply via email to

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