Andi Kleen wrote:
> Gregory Haskins <ghaskins@xxxxxxxxxx> writes:
>
> What might be useful is if you could expand a bit more on what the high level
> use cases for this.
>
> Questions that come to mind and that would be good to answer:
>
> This seems to be aimed at having multiple VMs talk
> to each other, but not talk to the rest of the world, correct?
> Is that a common use case?
>
Actually we didn't design specifically for either type of environment.
I think it would, in fact, be well suited to either type of
communication model, even concurrently (e.g. an intra-vm ipc channel
resource could live right on the same bus as a virtio-net and a
virtio-disk resource)
> Wouldn't they typically have a default route anyways and be able to talk to each
> other this way?
> And why can't any such isolation be done with standard firewalling? (it's known that
> current iptables has some scalability issues, but there's work going on right
> now to fix that).
>
vbus itself, and even some of the higher level constructs we apply on
top of it (like venet) are at a different scope than I think what you
are getting at above. Yes, I suppose you could create a private network
using the existing virtio-net + iptables. But you could also do the
same using virtio-net and a private bridge devices as well. That is not
what we are trying to address.
What we *are* trying to address is making an easy way to declare virtual
resources directly in the kernel so that they can be accessed more
efficiently. Contrast that to the way its done today, where the models
live in, say, qemu userspace.
So instead of having
guest->host->qemu::virtio-net->tap->[iptables|bridge], you simply have
guest->host->[iptables|bridge]. How you make your private network (if
that is what you want to do) is orthogonal...its the path to get there
that we changed.
> What would be the use cases for non networking devices?
>
> How would the interfaces to the user look like?
>
I am not sure if you are asking about the guests perspective or the
host-administators perspective.
First now lets look at the low-level device interface from the guests
perspective. We can cover the admin perspective in a separate doc, if
need be.
Each device in vbus supports two basic verbs: CALL, and SHM
int (*call)(struct vbus_device_proxy *dev, u32 func,
void *data, size_t len, int flags);
int (*shm)(struct vbus_device_proxy *dev, int id, int prio,
void *ptr, size_t len,
struct shm_signal_desc *sigdesc, struct shm_signal **signal,
int flags);
CALL provides a synchronous method for invoking some verb on the device
(defined by "func") with some arbitrary data. The namespace for "func"
is part of the ABI for the device in question. It is analogous to an
ioctl, with the primary difference being that its remotable (it invokes
from the guest driver across to the host device).
SHM provides a way to register shared-memory with the device which can
be used for asynchronous communication. The memory is always owned by
the "north" (the guest), while the "south" (the host) simply maps it
into its address space. You can optionally establish a shm_signal
object on this memory for signaling in either direction, and I
anticipate most shm regions will use this feature. Each shm region has
an "id" namespace, which like the "func" namespace from the CALL method
is completely owned by the device ABI. For example, we have might have
id's of "RX-RING" and "TX-RING", etc.
From there, we can (hopefully) build an arbitrary type of IO service to
map on top. So for instance, for venet-tap, we have CALL verbs for
things like MACQUERY, and LINKUP, and we have SHM ids for RX-QUEUE and
TX-QUEUE. We can write a driver that speaks this ABI on the bottom
edge, and presents a normal netif interface on the top edge. So the
actual consumption of these resources can look just like another other
resource of a similar type.
-Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
