[lkml]   [2009]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 00/17] virtual-bus
    Andi Kleen wrote:
    > Gregory Haskins <> 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.


    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2009-04-01 14:05    [W:0.025 / U:204.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site