From: Paul Brook <paul@codesourcery.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Mon, 22 Mar 2010 21:00:59 +0000 [thread overview]
Message-ID: <201003222101.00061.paul@codesourcery.com> (raw)
In-Reply-To: <4BA7BB8F.9070601@codemonkey.ws>
> 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
next prev parent reply other threads:[~2010-03-22 21:01 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-16 18:51 [Qemu-devel] [PATCH 0/9] Virtio cleanups Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 1/9] qemu/pci: document msix_entries_nr field Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 2/9] virtio: Teach virtio-balloon about DO_UPCAST Juan Quintela
2010-03-18 7:29 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 3/9] virtio: Teach virtio-blk " Juan Quintela
2010-03-18 7:29 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 4/9] virtio: Teach virtio-net " Juan Quintela
2010-03-18 7:29 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 5/9] virtio: Use DO_UPCAST instead of a cast Juan Quintela
2010-03-18 7:30 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 6/9] virtio-pci: Remove duplicate test Juan Quintela
2010-03-18 7:25 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-18 8:26 ` Juan Quintela
2010-03-18 8:47 ` Michael S. Tsirkin
2010-03-18 8:59 ` Juan Quintela
2010-03-18 9:11 ` Michael S. Tsirkin
2010-03-18 11:40 ` Juan Quintela
2010-03-18 13:24 ` Michael S. Tsirkin
2010-03-18 13:47 ` Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 7/9] QLIST: Introduce QLIST_COPY_HEAD Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 8/9] virtio-blk: change rq type to VirtIOBlockReq Juan Quintela
2010-03-18 7:27 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 9/9] virtio-blk: use QLIST for the list of requests Juan Quintela
2010-03-18 6:40 ` [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups Michael S. Tsirkin
2010-03-18 7:36 ` Juan Quintela
2010-03-18 7:42 ` Michael S. Tsirkin
2010-03-18 8:36 ` Juan Quintela
2010-03-18 9:07 ` Michael S. Tsirkin
2010-03-18 11:53 ` Juan Quintela
2010-03-18 12:33 ` Michael S. Tsirkin
2010-03-18 13:43 ` Juan Quintela
2010-03-18 13:47 ` Michael S. Tsirkin
2010-03-18 14:21 ` Juan Quintela
2010-03-18 17:13 ` Michael S. Tsirkin
2010-03-19 1:41 ` Jamie Lokier
2010-03-21 14:31 ` Michael S. Tsirkin
2010-03-21 18:11 ` Jamie Lokier
2010-03-21 19:16 ` Michael S. Tsirkin
2010-03-22 1:06 ` Juan Quintela
2010-03-22 2:51 ` Anthony Liguori
2010-03-22 13:30 ` Paul Brook
2010-03-22 14:49 ` Anthony Liguori
2010-03-22 14:50 ` Michael S. Tsirkin
2010-03-22 15:03 ` Anthony Liguori
2010-03-22 15:17 ` Michael S. Tsirkin
2010-03-22 15:50 ` Anthony Liguori
2010-03-22 16:16 ` Paul Brook
2010-03-22 18:48 ` Anthony Liguori
2010-03-22 21:00 ` Paul Brook [this message]
2010-03-23 1:13 ` Anthony Liguori
2010-03-22 15:51 ` Paul Brook
2010-03-22 17:19 ` Michael S. Tsirkin
2010-03-22 22:16 ` Juan Quintela
2010-03-23 0:49 ` Paul Brook
2010-03-23 1:16 ` Anthony Liguori
2010-03-23 10:47 ` Michael S. Tsirkin
2010-03-23 11:11 ` Gerd Hoffmann
2010-03-23 11:40 ` Paul Brook
2010-03-23 11:58 ` Michael S. Tsirkin
2010-03-23 12:32 ` Juan Quintela
2010-03-21 19:57 ` Michael S. Tsirkin
2010-03-22 1:13 ` Juan Quintela
2010-03-22 8:37 ` Michael S. Tsirkin
2010-03-18 10:05 ` Michael S. Tsirkin
2010-03-18 15:43 ` Gerd Hoffmann
2010-03-18 16:20 ` Juan Quintela
2010-03-18 16:36 ` Gerd Hoffmann
2010-03-18 17:08 ` Juan Quintela
2010-03-18 17:21 ` Michael S. Tsirkin
2010-03-18 19:37 ` Juan Quintela
2010-03-18 20:07 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003222101.00061.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=anthony@codemonkey.ws \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.