Prev: bfa: Brocade BFA FC SCSI driver (bfad)
Next: Atheros Linux wireless drivers home page - and two new driver projects
From: Ira W. Snyder on 24 Sep 2009 15:30
On Thu, Sep 24, 2009 at 10:18:28AM +0300, Avi Kivity wrote:
> On 09/24/2009 12:15 AM, Gregory Haskins wrote:
> >
> >>> There are various aspects about designing high-performance virtual
> >>> devices such as providing the shortest paths possible between the
> >>> physical resources and the consumers. Conversely, we also need to
> >>> ensure that we meet proper isolation/protection guarantees at the same
> >>> time. What this means is there are various aspects to any
> >>> high-performance PV design that require to be placed in-kernel to
> >>> maximize the performance yet properly isolate the guest.
> >>>
> >>> For instance, you are required to have your signal-path (interrupts and
> >>> hypercalls), your memory-path (gpa translation), and
> >>> addressing/isolation model in-kernel to maximize performance.
> >>>
> >>>
> >> Exactly. That's what vhost puts into the kernel and nothing more.
> >>
> > Actually, no. Generally, _KVM_ puts those things into the kernel, and
> > vhost consumes them. Without KVM (or something equivalent), vhost is
> > incomplete. One of my goals with vbus is to generalize the "something
> > equivalent" part here.
> >
>
> I don't really see how vhost and vbus are different here. vhost expects
> signalling to happen through a couple of eventfds and requires someone
> to supply them and implement kernel support (if needed). vbus requires
> someone to write a connector to provide the signalling implementation.
> Neither will work out-of-the-box when implementing virtio-net over
> falling dominos, for example.
>
> >>> Vbus accomplishes its in-kernel isolation model by providing a
> >>> "container" concept, where objects are placed into this container by
> >>> userspace. The host kernel enforces isolation/protection by using a
> >>> namespace to identify objects that is only relevant within a specific
> >>> container's context (namely, a "u32 dev-id"). The guest addresses the
> >>> objects by its dev-id, and the kernel ensures that the guest can't
> >>> access objects outside of its dev-id namespace.
> >>>
> >>>
> >> vhost manages to accomplish this without any kernel support.
> >>
> > No, vhost manages to accomplish this because of KVMs kernel support
> > (ioeventfd, etc). Without a KVM-like in-kernel support, vhost is a
> > merely a kind of "tuntap"-like clone signalled by eventfds.
> >
>
> Without a vbus-connector-falling-dominos, vbus-venet can't do anything
> either. Both vhost and vbus need an interface, vhost's is just narrower
> since it doesn't do configuration or enumeration.
>
> > This goes directly to my rebuttal of your claim that vbus places too
> > much in the kernel. I state that, one way or the other, address decode
> > and isolation _must_ be in the kernel for performance. Vbus does this
> > with a devid/container scheme. vhost+virtio-pci+kvm does it with
> > pci+pio+ioeventfd.
> >
>
> vbus doesn't do kvm guest address decoding for the fast path. It's
> still done by ioeventfd.
>
> >> The guest
> >> simply has not access to any vhost resources other than the guest->host
> >> doorbell, which is handed to the guest outside vhost (so it's somebody
> >> else's problem, in userspace).
> >>
> > You mean _controlled_ by userspace, right? Obviously, the other side of
> > the kernel still needs to be programmed (ioeventfd, etc). Otherwise,
> > vhost would be pointless: e.g. just use vanilla tuntap if you don't need
> > fast in-kernel decoding.
> >
>
> Yes (though for something like level-triggered interrupts we're probably
> keeping it in userspace, enjoying the benefits of vhost data path while
> paying more for signalling).
>
> >>> All that is required is a way to transport a message with a "devid"
> >>> attribute as an address (such as DEVCALL(devid)) and the framework
> >>> provides the rest of the decode+execute function.
> >>>
> >>>
> >> vhost avoids that.
> >>
> > No, it doesn't avoid it. It just doesn't specify how its done, and
> > relies on something else to do it on its behalf.
> >
>
> That someone else can be in userspace, apart from the actual fast path.
>
> > Conversely, vbus specifies how its done, but not how to transport the
> > verb "across the wire". That is the role of the vbus-connector abstraction.
> >
>
> So again, vbus does everything in the kernel (since it's so easy and
> cheap) but expects a vbus-connector. vhost does configuration in
> userspace (since it's so clunky and fragile) but expects a couple of
> eventfds.
>
> >>> Contrast this to vhost+virtio-pci (called simply "vhost" from here).
> >>>
> >>>
> >> It's the wrong name. vhost implements only the data path.
> >>
> > Understood, but vhost+virtio-pci is what I am contrasting, and I use
> > "vhost" for short from that point on because I am too lazy to type the
> > whole name over and over ;)
> >
>
> If you #define A A+B+C don't expect intelligent conversation afterwards.
>
> >>> It is not immune to requiring in-kernel addressing support either, but
> >>> rather it just does it differently (and its not as you might expect via
> >>> qemu).
> >>>
> >>> Vhost relies on QEMU to render PCI objects to the guest, which the guest
> >>> assigns resources (such as BARs, interrupts, etc).
> >>>
> >> vhost does not rely on qemu. It relies on its user to handle
> >> configuration. In one important case it's qemu+pci. It could just as
> >> well be the lguest launcher.
> >>
> > I meant vhost=vhost+virtio-pci here. Sorry for the confusion.
> >
> > The point I am making specifically is that vhost in general relies on
> > other in-kernel components to function. I.e. It cannot function without
> > having something like the PCI model to build an IO namespace. That
> > namespace (in this case, pio addresses+data tuples) are used for the
> > in-kernel addressing function under KVM + virtio-pci.
> >
> > The case of the lguest launcher is a good one to highlight. Yes, you
> > can presumably also use lguest with vhost, if the requisite facilities
> > are exposed to lguest-bus, and some eventfd based thing like ioeventfd
> > is written for the host (if it doesnt exist already).
> >
> > And when the next virt design "foo" comes out, it can make a "foo-bus"
> > model, and implement foo-eventfd on the backend, etc, etc.
> >
>
> It's exactly the same with vbus needing additional connectors for
> additional transports.
>
> > Ira can make ira-bus, and ira-eventfd, etc, etc.
> >
> > Each iteration will invariably introduce duplicated parts of the stack.
> >
>
> Invariably? Use libraries (virtio-shmem.ko, libvhost.so).
>

Referencing libraries that don't yet exist doesn't seem like a good
argument against vbus from my point of view. I'm not speficially
advocating for vbus; I'm just letting you know how it looks to another
developer in the trenches.

If you'd like to see the amount of duplication present, look at the code
I'm currently working on. It mostly works at this point, though I
haven't finished my userspace, nor figured out how to actually transfer
data.

The current question I have (just to let you know where I am in
development) is:

I have the physical address of the remote data, but how do I get it into
a userspace buffer, so I can pass it to tun?

http://www.mmarray.org/~iws/virtio-phys/

Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 25 Sep 2009 03:50
On 09/24/2009 10:27 PM, Ira W. Snyder wrote:
>>> Ira can make ira-bus, and ira-eventfd, etc, etc.
>>>
>>> Each iteration will invariably introduce duplicated parts of the stack.
>>>
>>>
>> Invariably? Use libraries (virtio-shmem.ko, libvhost.so).
>>
>>
> Referencing libraries that don't yet exist doesn't seem like a good
> argument against vbus from my point of view. I'm not speficially
> advocating for vbus; I'm just letting you know how it looks to another
> developer in the trenches.
>

My argument is that we shouldn't write a new framework instead of fixing
or extending an existing one.

> If you'd like to see the amount of duplication present, look at the code
> I'm currently working on.

Yes, virtio-phys-guest looks pretty much duplicated. Looks like it
should be pretty easy to deduplicate.

> It mostly works at this point, though I
> haven't finished my userspace, nor figured out how to actually transfer
> data.
>
> The current question I have (just to let you know where I am in
> development) is:
>
> I have the physical address of the remote data, but how do I get it into
> a userspace buffer, so I can pass it to tun?
>

vhost does guest physical address to host userspace address (it your
scenario, remote physical to local virtual) using a table of memory
slots; there's an ioctl that allows userspace to initialize that table.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 25 Sep 2009 04:30
On 09/24/2009 09:03 PM, Gregory Haskins wrote:
>
>> I don't really see how vhost and vbus are different here. vhost expects
>> signalling to happen through a couple of eventfds and requires someone
>> to supply them and implement kernel support (if needed). vbus requires
>> someone to write a connector to provide the signalling implementation.
>> Neither will work out-of-the-box when implementing virtio-net over
>> falling dominos, for example.
>>
> I realize in retrospect that my choice of words above implies vbus _is_
> complete, but this is not what I was saying. What I was trying to
> convey is that vbus is _more_ complete. Yes, in either case some kind
> of glue needs to be written. The difference is that vbus implements
> more of the glue generally, and leaves less required to be customized
> for each iteration.
>


No argument there. Since you care about non-virt scenarios and virtio
doesn't, naturally vbus is a better fit for them as the code stands.
But that's not a strong argument for vbus; instead of adding vbus you
could make virtio more friendly to non-virt (there's a limit how far you
can take this, not imposed by the code, but by virtio's charter as a
virtual device driver framework).

> Going back to our stack diagrams, you could think of a vhost solution
> like this:
>
> --------------------------
> | virtio-net
> --------------------------
> | virtio-ring
> --------------------------
> | virtio-bus
> --------------------------
> | ? undefined-1 ?
> --------------------------
> | vhost
> --------------------------
>
> and you could think of a vbus solution like this
>
> --------------------------
> | virtio-net
> --------------------------
> | virtio-ring
> --------------------------
> | virtio-bus
> --------------------------
> | bus-interface
> --------------------------
> | ? undefined-2 ?
> --------------------------
> | bus-model
> --------------------------
> | virtio-net-device (vhost ported to vbus model? :)
> --------------------------
>
>
> So the difference between vhost and vbus in this particular context is
> that you need to have "undefined-1" do device discovery/hotswap,
> config-space, address-decode/isolation, signal-path routing, memory-path
> routing, etc. Today this function is filled by things like virtio-pci,
> pci-bus, KVM/ioeventfd, and QEMU for x86. I am not as familiar with
> lguest, but presumably it is filled there by components like
> virtio-lguest, lguest-bus, lguest.ko, and lguest-launcher. And to use
> more contemporary examples, we might have virtio-domino, domino-bus,
> domino.ko, and domino-launcher as well as virtio-ira, ira-bus, ira.ko,
> and ira-launcher.
>
> Contrast this to the vbus stack: The bus-X components (when optionally
> employed by the connector designer) do device-discovery, hotswap,
> config-space, address-decode/isolation, signal-path and memory-path
> routing, etc in a general (and pv-centric) way. The "undefined-2"
> portion is the "connector", and just needs to convey messages like
> "DEVCALL" and "SHMSIGNAL". The rest is handled in other parts of the stack.
>
>

Right. virtio assumes that it's in a virt scenario and that the guest
architecture already has enumeration and hotplug mechanisms which it
would prefer to use. That happens to be the case for kvm/x86.

> So to answer your question, the difference is that the part that has to
> be customized in vbus should be a fraction of what needs to be
> customized with vhost because it defines more of the stack.

But if you want to use the native mechanisms, vbus doesn't have any
added value.

> And, as
> eluded to in my diagram, both virtio-net and vhost (with some
> modifications to fit into the vbus framework) are potentially
> complementary, not competitors.
>

Only theoretically. The existing installed base would have to be thrown
away, or we'd need to support both.




>> Without a vbus-connector-falling-dominos, vbus-venet can't do anything
>> either.
>>
> Mostly covered above...
>
> However, I was addressing your assertion that vhost somehow magically
> accomplishes this "container/addressing" function without any specific
> kernel support. This is incorrect. I contend that this kernel support
> is required and present. The difference is that its defined elsewhere
> (and typically in a transport/arch specific way).
>
> IOW: You can basically think of the programmed PIO addresses as forming
> its "container". Only addresses explicitly added are visible, and
> everything else is inaccessible. This whole discussion is merely a
> question of what's been generalized verses what needs to be
> re-implemented each time.
>

Sorry, this is too abstract for me.



>> vbus doesn't do kvm guest address decoding for the fast path. It's
>> still done by ioeventfd.
>>
> That is not correct. vbus does its own native address decoding in the
> fast path, such as here:
>
> http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/client.c;h=e85b2d92d629734866496b67455dd307486e394a;hb=e6cbd4d1decca8e829db3b2b9b6ec65330b379e9#l331
>
>

All this is after kvm has decoded that vbus is addresses. It can't work
without someone outside vbus deciding that.

> In fact, it's actually a simpler design to unify things this way because
> you avoid splitting the device model up. Consider how painful the vhost
> implementation would be if it didn't already have the userspace
> virtio-net to fall-back on. This is effectively what we face for new
> devices going forward if that model is to persist.
>


It doesn't have just virtio-net, it has userspace-based hostplug and a
bunch of other devices impemented in userspace. Currently qemu has
virtio bindings for pci and syborg (whatever that is), and device models
for baloon, block, net, and console, so it seems implementing device
support in userspace is not as disasterous as you make it to be.

>> Invariably?
>>
> As in "always"
>

Refactor instead of duplicating.

>
>> Use libraries (virtio-shmem.ko, libvhost.so).
>>
> What do you suppose vbus is? vbus-proxy.ko = virtio-shmem.ko, and you
> dont need libvhost.so per se since you can just use standard kernel
> interfaces (like configfs/sysfs). I could create an .so going forward
> for the new ioctl-based interface, I suppose.
>

Refactor instead of rewriting.



>> For kvm/x86 pci definitely remains king.
>>
> For full virtualization, sure. I agree. However, we are talking about
> PV here. For PV, PCI is not a requirement and is a technical dead-end IMO.
>
> KVM seems to be the only virt solution that thinks otherwise (*), but I
> believe that is primarily a condition of its maturity. I aim to help
> advance things here.
>
> (*) citation: xen has xenbus, lguest has lguest-bus, vmware has some
> vmi-esq thing (I forget what its called) to name a few. Love 'em or
> hate 'em, most other hypervisors do something along these lines. I'd
> like to try to create one for KVM, but to unify them all (at least for
> the Linux-based host designs).
>

VMware are throwing VMI away (won't be supported in their new product,
and they've sent a patch to rip it off from Linux); Xen has to tunnel
xenbus in pci for full virtualization (which is where Windows is, and
where Linux will be too once people realize it's faster). lguest is
meant as an example hypervisor, not an attempt to take over the world.

"PCI is a dead end" could not be more wrong, it's what guests support.
An right now you can have a guest using pci to access a mix of
userspace-emulated devices, userspace-emulated-but-kernel-accelerated
virtio devices, and real host devices. All on one dead-end bus. Try
that with vbus.


>>> I digress. My point here isn't PCI. The point here is the missing
>>> component for when PCI is not present. The component that is partially
>>> satisfied by vbus's devid addressing scheme. If you are going to use
>>> vhost, and you don't have PCI, you've gotta build something to replace
>>> it.
>>>
>>>
>> Yes, that's why people have keyboards. They'll write that glue code if
>> they need it. If it turns out to be a hit an people start having virtio
>> transport module writing parties, they'll figure out a way to share code.
>>
> Sigh... The party has already started. I tried to invite you months ago...
>

I've been voting virtio since 2007.

>> On the guest side, virtio-shmem.ko can unify the ring access. It
>> probably makes sense even today. On the host side I eventfd is the
>> kernel interface and libvhostconfig.so can provide the configuration
>> when an existing ABI is not imposed.
>>
> That won't cut it. For one, creating an eventfd is only part of the
> equation. I.e. you need to have originate/terminate somewhere
> interesting (and in-kernel, otherwise use tuntap).
>

vbus needs the same thing so it cancels out.

>> Look at the virtio-net feature negotiation. There's a lot more there
>> than the MAC address, and it's going to grow.
>>
> Agreed, but note that makes my point. That feature negotiation almost
> invariably influences the device-model, not some config-space shim.
> IOW: terminating config-space at some userspace shim is pointless. The
> model ultimately needs the result of whatever transpires during that
> negotiation anyway.
>

Well, let's see. Can vbus today:

- let userspace know which features are available (so it can decide if
live migration is possible)
- let userspace limit which features are exposed to the guest (so it can
make live migration possible among hosts of different capabilities)
- let userspace know which features were negotiated (so it can transfer
them to the other host during live migration)
- let userspace tell the kernel which features were negotiated (when
live migration completes, to avoid requiring the guest to re-negotiate)
- do all that from an unprivileged process
- securely wrt other unprivileged processes

?

What are your plans here?



--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ira W. Snyder on 25 Sep 2009 13:10
On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> What it is: vhost net is a character device that can be used to reduce
> the number of system calls involved in virtio networking.
> Existing virtio net code is used in the guest without modification.
>
> There's similarity with vringfd, with some differences and reduced scope
> - uses eventfd for signalling
> - structures can be moved around in memory at any time (good for migration)
> - support memory table and not just an offset (needed for kvm)
>
> common virtio related code has been put in a separate file vhost.c and
> can be made into a separate module if/when more backends appear. I used
> Rusty's lguest.c as the source for developing this part : this supplied
> me with witty comments I wouldn't be able to write myself.
>
> What it is not: vhost net is not a bus, and not a generic new system
> call. No assumptions are made on how guest performs hypercalls.
> Userspace hypervisors are supported as well as kvm.
>
> How it works: Basically, we connect virtio frontend (configured by
> userspace) to a backend. The backend could be a network device, or a
> tun-like device. In this version I only support raw socket as a backend,
> which can be bound to e.g. SR IOV, or to macvlan device. Backend is
> also configured by userspace, including vlan/mac etc.
>
> Status:
> This works for me, and I haven't see any crashes.
> I have done some light benchmarking (with v4), compared to userspace, I
> see improved latency (as I save up to 4 system calls per packet) but not
> bandwidth/CPU (as TSO and interrupt mitigation are not supported). For
> ping benchmark (where there's no TSO) troughput is also improved.
>
> Features that I plan to look at in the future:
> - tap support
> - TSO
> - interrupt mitigation
> - zero copy
>
> Acked-by: Arnd Bergmann <arnd(a)arndb.de>
> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
>
> ---
> MAINTAINERS | 10 +
> arch/x86/kvm/Kconfig | 1 +
> drivers/Makefile | 1 +
> drivers/vhost/Kconfig | 11 +
> drivers/vhost/Makefile | 2 +
> drivers/vhost/net.c | 475 ++++++++++++++++++++++++++++++
> drivers/vhost/vhost.c | 688 ++++++++++++++++++++++++++++++++++++++++++++
> drivers/vhost/vhost.h | 122 ++++++++
> include/linux/Kbuild | 1 +
> include/linux/miscdevice.h | 1 +
> include/linux/vhost.h | 101 +++++++
> 11 files changed, 1413 insertions(+), 0 deletions(-)
> create mode 100644 drivers/vhost/Kconfig
> create mode 100644 drivers/vhost/Makefile
> create mode 100644 drivers/vhost/net.c
> create mode 100644 drivers/vhost/vhost.c
> create mode 100644 drivers/vhost/vhost.h
> create mode 100644 include/linux/vhost.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b1114cf..de4587f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5431,6 +5431,16 @@ S: Maintained
> F: Documentation/filesystems/vfat.txt
> F: fs/fat/
>
> +VIRTIO HOST (VHOST)
> +P: Michael S. Tsirkin
> +M: mst(a)redhat.com
> +L: kvm(a)vger.kernel.org
> +L: virtualization(a)lists.osdl.org
> +L: netdev(a)vger.kernel.org
> +S: Maintained
> +F: drivers/vhost/
> +F: include/linux/vhost.h
> +
> VIA RHINE NETWORK DRIVER
> M: Roger Luethi <rl(a)hellgate.ch>
> S: Maintained
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index b84e571..94f44d9 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -64,6 +64,7 @@ config KVM_AMD
>
> # OK, it's a little counter-intuitive to do this, but it puts it neatly under
> # the virtualization menu.
> +source drivers/vhost/Kconfig
> source drivers/lguest/Kconfig
> source drivers/virtio/Kconfig
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index bc4205d..1551ae1 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -105,6 +105,7 @@ obj-$(CONFIG_HID) += hid/
> obj-$(CONFIG_PPC_PS3) += ps3/
> obj-$(CONFIG_OF) += of/
> obj-$(CONFIG_SSB) += ssb/
> +obj-$(CONFIG_VHOST_NET) += vhost/
> obj-$(CONFIG_VIRTIO) += virtio/
> obj-$(CONFIG_VLYNQ) += vlynq/
> obj-$(CONFIG_STAGING) += staging/
> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> new file mode 100644
> index 0000000..d955406
> --- /dev/null
> +++ b/drivers/vhost/Kconfig
> @@ -0,0 +1,11 @@
> +config VHOST_NET
> + tristate "Host kernel accelerator for virtio net"
> + depends on NET && EVENTFD
> + ---help---
> + This kernel module can be loaded in host kernel to accelerate
> + guest networking with virtio_net. Not to be confused with virtio_net
> + module itself which needs to be loaded in guest kernel.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called vhost_net.
> +
> diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> new file mode 100644
> index 0000000..72dd020
> --- /dev/null
> +++ b/drivers/vhost/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_VHOST_NET) += vhost_net.o
> +vhost_net-y := vhost.o net.o
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> new file mode 100644
> index 0000000..2210eaa
> --- /dev/null
> +++ b/drivers/vhost/net.c
> @@ -0,0 +1,475 @@
> +/* Copyright (C) 2009 Red Hat, Inc.
> + * Author: Michael S. Tsirkin <mst(a)redhat.com>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.
> + *
> + * virtio-net server in host kernel.
> + */
> +
> +#include <linux/compat.h>
> +#include <linux/eventfd.h>
> +#include <linux/vhost.h>
> +#include <linux/virtio_net.h>
> +#include <linux/mmu_context.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/workqueue.h>
> +#include <linux/rcupdate.h>
> +#include <linux/file.h>
> +
> +#include <linux/net.h>
> +#include <linux/if_packet.h>
> +#include <linux/if_arp.h>
> +
> +#include <net/sock.h>
> +
> +#include "vhost.h"
> +
> +enum {
> + VHOST_NET_VQ_RX = 0,
> + VHOST_NET_VQ_TX = 1,
> + VHOST_NET_VQ_MAX = 2,
> +};
> +
> +struct vhost_net {
> + struct vhost_dev dev;
> + struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
> + /* We use a kind of RCU to access sock pointer.
> + * All readers access it from workqueue, which makes it possible to
> + * flush the workqueue instead of synchronize_rcu. Therefore readers do
> + * not need to call rcu_read_lock/rcu_read_unlock: the beginning of
> + * work item execution acts instead of rcu_read_lock() and the end of
> + * work item execution acts instead of rcu_read_lock().
> + * Writers use device mutex. */
> + struct socket *sock;
> + struct vhost_poll poll[VHOST_NET_VQ_MAX];
> +};
> +
> +/* Pop first len bytes from iovec. Return number of segments used. */
> +static int move_iovec_hdr(struct iovec *from, struct iovec *to,
> + size_t len, int iov_count)
> +{
> + int seg = 0;
> + size_t size;
> + while (len && seg < iov_count) {
> + size = min(from->iov_len, len);
> + to->iov_base = from->iov_base;
> + to->iov_len = size;
> + from->iov_len -= size;
> + from->iov_base += size;
> + len -= size;
> + ++from;
> + ++to;
> + ++seg;
> + }
> + return seg;
> +}
> +
> +/* Expects to be always run from workqueue - which acts as
> + * read-size critical section for our kind of RCU. */
> +static void handle_tx(struct vhost_net *net)
> +{
> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
> + unsigned head, out, in, s;
> + struct msghdr msg = {
> + .msg_name = NULL,
> + .msg_namelen = 0,
> + .msg_control = NULL,
> + .msg_controllen = 0,
> + .msg_iov = vq->iov,
> + .msg_flags = MSG_DONTWAIT,
> + };
> + size_t len;
> + int err;
> + struct socket *sock = rcu_dereference(net->sock);
> + if (!sock || !sock_writeable(sock->sk))
> + return;
> +
> + use_mm(net->dev.mm);
> + mutex_lock(&vq->mutex);
> + for (;;) {
> + head = vhost_get_vq_desc(&net->dev, vq, vq->iov, &out, &in);
> + /* Nothing new? Wait for eventfd to tell us they refilled. */
> + if (head == vq->num)
> + break;
> + if (in) {
> + vq_err(vq, "Unexpected descriptor format for TX: "
> + "out %d, int %d\n", out, in);
> + break;
> + }
> + /* Skip header. TODO: support TSO. */
> + s = move_iovec_hdr(vq->iov, vq->hdr,
> + sizeof(struct virtio_net_hdr), out);
> + msg.msg_iovlen = out;
> + len = iov_length(vq->iov, out);
> + /* Sanity check */
> + if (!len) {
> + vq_err(vq, "Unexpected header len for TX: "
> + "%ld expected %zd\n",
> + iov_length(vq->hdr, s),
> + sizeof(struct virtio_net_hdr));
> + break;
> + }
> + /* TODO: Check specific error and bomb out unless ENOBUFS? */
> + err = sock->ops->sendmsg(NULL, sock, &msg, len);
> + if (err < 0) {
> + vhost_discard_vq_desc(vq);
> + break;
> + }
> + if (err != len)
> + pr_err("Truncated TX packet: "
> + " len %d != %zd\n", err, len);
> + vhost_add_used_and_trigger(&net->dev, vq, head, 0);
> + }
> +
> + mutex_unlock(&vq->mutex);
> + unuse_mm(net->dev.mm);
> +}
> +
> +/* Expects to be always run from workqueue - which acts as
> + * read-size critical section for our kind of RCU. */
> +static void handle_rx(struct vhost_net *net)
> +{
> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_RX];
> + unsigned head, out, in, s;
> + struct msghdr msg = {
> + .msg_name = NULL,
> + .msg_namelen = 0,
> + .msg_control = NULL, /* FIXME: get and handle RX aux data. */
> + .msg_controllen = 0,
> + .msg_iov = vq->iov,
> + .msg_flags = MSG_DONTWAIT,
> + };
> +
> + struct virtio_net_hdr hdr = {
> + .flags = 0,
> + .gso_type = VIRTIO_NET_HDR_GSO_NONE
> + };
> +
> + size_t len;
> + int err;
> + struct socket *sock = rcu_dereference(net->sock);
> + if (!sock || skb_queue_empty(&sock->sk->sk_receive_queue))
> + return;
> +
> + use_mm(net->dev.mm);
> + mutex_lock(&vq->mutex);
> + vhost_no_notify(vq);
> +
> + for (;;) {
> + head = vhost_get_vq_desc(&net->dev, vq, vq->iov, &out, &in);
> + /* OK, now we need to know about added descriptors. */
> + if (head == vq->num && vhost_notify(vq))
> + /* They could have slipped one in as we were doing that:
> + * check again. */
> + continue;
> + /* Nothing new? Wait for eventfd to tell us they refilled. */
> + if (head == vq->num)
> + break;
> + /* We don't need to be notified again. */
> + vhost_no_notify(vq);
> + if (out) {
> + vq_err(vq, "Unexpected descriptor format for RX: "
> + "out %d, int %d\n",
> + out, in);
> + break;
> + }
> + /* Skip header. TODO: support TSO/mergeable rx buffers. */
> + s = move_iovec_hdr(vq->iov, vq->hdr, sizeof hdr, in);
> + msg.msg_iovlen = in;
> + len = iov_length(vq->iov, in);
> + /* Sanity check */
> + if (!len) {
> + vq_err(vq, "Unexpected header len for RX: "
> + "%zd expected %zd\n",
> + iov_length(vq->hdr, s), sizeof hdr);
> + break;
> + }
> + err = sock->ops->recvmsg(NULL, sock, &msg,
> + len, MSG_DONTWAIT | MSG_TRUNC);
> + /* TODO: Check specific error and bomb out unless EAGAIN? */
> + if (err < 0) {
> + vhost_discard_vq_desc(vq);
> + break;
> + }
> + /* TODO: Should check and handle checksum. */
> + if (err > len) {
> + pr_err("Discarded truncated rx packet: "
> + " len %d > %zd\n", err, len);
> + vhost_discard_vq_desc(vq);
> + continue;
> + }
> + len = err;
> + err = memcpy_toiovec(vq->hdr, (unsigned char *)&hdr, sizeof hdr);
> + if (err) {
> + vq_err(vq, "Unable to write vnet_hdr at addr %p: %d\n",
> + vq->iov->iov_base, err);
> + break;
> + }
> + vhost_add_used_and_trigger(&net->dev, vq, head,
> + len + sizeof hdr);
> + }
> +
> + mutex_unlock(&vq->mutex);
> + unuse_mm(net->dev.mm);
> +}
> +
> +static void handle_tx_kick(struct work_struct *work)
> +{
> + struct vhost_virtqueue *vq;
> + struct vhost_net *net;
> + vq = container_of(work, struct vhost_virtqueue, poll.work);
> + net = container_of(vq->dev, struct vhost_net, dev);
> + handle_tx(net);
> +}
> +
> +static void handle_rx_kick(struct work_struct *work)
> +{
> + struct vhost_virtqueue *vq;
> + struct vhost_net *net;
> + vq = container_of(work, struct vhost_virtqueue, poll.work);
> + net = container_of(vq->dev, struct vhost_net, dev);
> + handle_rx(net);
> +}
> +
> +static void handle_tx_net(struct work_struct *work)
> +{
> + struct vhost_net *net;
> + net = container_of(work, struct vhost_net, poll[VHOST_NET_VQ_TX].work);
> + handle_tx(net);
> +}
> +
> +static void handle_rx_net(struct work_struct *work)
> +{
> + struct vhost_net *net;
> + net = container_of(work, struct vhost_net, poll[VHOST_NET_VQ_RX].work);
> + handle_rx(net);
> +}
> +
> +static int vhost_net_open(struct inode *inode, struct file *f)
> +{
> + struct vhost_net *n = kzalloc(sizeof *n, GFP_KERNEL);
> + int r;
> + if (!n)
> + return -ENOMEM;
> + f->private_data = n;
> + n->vqs[VHOST_NET_VQ_TX].handle_kick = handle_tx_kick;
> + n->vqs[VHOST_NET_VQ_RX].handle_kick = handle_rx_kick;
> + r = vhost_dev_init(&n->dev, n->vqs, VHOST_NET_VQ_MAX);
> + if (r < 0) {
> + kfree(n);
> + return r;
> + }
> +
> + vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT);
> + vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN);
> + return 0;
> +}
> +
> +static struct socket *vhost_net_stop(struct vhost_net *n)
> +{
> + struct socket *sock = n->sock;
> + rcu_assign_pointer(n->sock, NULL);
> + if (sock) {
> + vhost_poll_flush(n->poll + VHOST_NET_VQ_TX);
> + vhost_poll_flush(n->poll + VHOST_NET_VQ_RX);
> + }
> + return sock;
> +}
> +
> +static int vhost_net_release(struct inode *inode, struct file *f)
> +{
> + struct vhost_net *n = f->private_data;
> + struct socket *sock;
> +
> + sock = vhost_net_stop(n);
> + vhost_dev_cleanup(&n->dev);
> + if (sock)
> + fput(sock->file);
> + kfree(n);
> + return 0;
> +}
> +
> +static void vhost_net_flush(struct vhost_net *n)
> +{
> + vhost_poll_flush(n->poll + VHOST_NET_VQ_TX);
> + vhost_poll_flush(n->poll + VHOST_NET_VQ_RX);
> + vhost_poll_flush(&n->dev.vqs[VHOST_NET_VQ_TX].poll);
> + vhost_poll_flush(&n->dev.vqs[VHOST_NET_VQ_RX].poll);
> +}
> +
> +static long vhost_net_set_socket(struct vhost_net *n, int fd)
> +{
> + struct {
> + struct sockaddr_ll sa;
> + char buf[MAX_ADDR_LEN];
> + } uaddr;
> + struct socket *sock, *oldsock = NULL;
> + int uaddr_len = sizeof uaddr, r;
> +
> + mutex_lock(&n->dev.mutex);
> + r = vhost_dev_check_owner(&n->dev);
> + if (r)
> + goto done;
> +
> + if (fd == -1) {
> + /* Disconnect from socket and device. */
> + oldsock = vhost_net_stop(n);
> + goto done;
> + }
> +
> + sock = sockfd_lookup(fd, &r);
> + if (!sock) {
> + r = -ENOTSOCK;
> + goto done;
> + }
> +
> + /* Parameter checking */
> + if (sock->sk->sk_type != SOCK_RAW) {
> + r = -ESOCKTNOSUPPORT;
> + goto done;
> + }
> +
> + r = sock->ops->getname(sock, (struct sockaddr *)&uaddr.sa,
> + &uaddr_len, 0);
> + if (r)
> + goto done;
> +
> + if (uaddr.sa.sll_family != AF_PACKET) {
> + r = -EPFNOSUPPORT;
> + goto done;
> + }
> +
> + /* start polling new socket */
> + if (sock == oldsock)
> + goto done;
> +
> + if (oldsock) {
> + vhost_poll_stop(n->poll + VHOST_NET_VQ_TX);
> + vhost_poll_stop(n->poll + VHOST_NET_VQ_RX);
> + }
> + oldsock = n->sock;
> + rcu_assign_pointer(n->sock, sock);
> + vhost_poll_start(n->poll + VHOST_NET_VQ_TX, sock->file);
> + vhost_poll_start(n->poll + VHOST_NET_VQ_RX, sock->file);
> +done:
> + mutex_unlock(&n->dev.mutex);
> + if (oldsock) {
> + vhost_net_flush(n);
> + fput(oldsock->file);
> + }
> + return r;
> +}
> +
> +static long vhost_net_reset_owner(struct vhost_net *n)
> +{
> + struct socket *sock = NULL;
> + long r;
> + mutex_lock(&n->dev.mutex);
> + r = vhost_dev_check_owner(&n->dev);
> + if (r)
> + goto done;
> + sock = vhost_net_stop(n);
> + r = vhost_dev_reset_owner(&n->dev);
> +done:
> + mutex_unlock(&n->dev.mutex);
> + if (sock)
> + fput(sock->file);
> + return r;
> +}
> +
> +static void vhost_net_set_features(struct vhost_net *n, u64 features)
> +{
> + mutex_unlock(&n->dev.mutex);
> + n->dev.acked_features = features;
> + mutex_unlock(&n->dev.mutex);
> + vhost_net_flush(n);
> +}
> +
> +static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
> + unsigned long arg)
> +{
> + struct vhost_net *n = f->private_data;
> + void __user *argp = (void __user *)arg;
> + u32 __user *featurep = argp;
> + int __user *fdp = argp;
> + u64 features;
> + int fd, r;
> + switch (ioctl) {
> + case VHOST_NET_SET_SOCKET:
> + r = get_user(fd, fdp);
> + if (r < 0)
> + return r;
> + return vhost_net_set_socket(n, fd);
> + case VHOST_GET_FEATURES:
> + features = VHOST_FEATURES;
> + return put_user(features, featurep);
> + case VHOST_ACK_FEATURES:
> + r = get_user(features, featurep);
> + /* No features for now */
> + if (r < 0)
> + return r;
> + if (features & ~VHOST_FEATURES)
> + return -EOPNOTSUPP;
> + vhost_net_set_features(n, features);
> + return 0;
> + case VHOST_RESET_OWNER:
> + return vhost_net_reset_owner(n);
> + default:
> + return vhost_dev_ioctl(&n->dev, ioctl, arg);
> + }
> +}
> +
> +#ifdef CONFIG_COMPAT
> +static long vhost_net_compat_ioctl(struct file *f, unsigned int ioctl,
> + unsigned long arg)
> +{
> + return vhost_net_ioctl(f, ioctl, (unsigned long)compat_ptr(arg));
> +}
> +#endif
> +
> +const static struct file_operations vhost_net_fops = {
> + .owner = THIS_MODULE,
> + .release = vhost_net_release,
> + .unlocked_ioctl = vhost_net_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = vhost_net_compat_ioctl,
> +#endif
> + .open = vhost_net_open,
> +};
> +
> +static struct miscdevice vhost_net_misc = {
> + VHOST_NET_MINOR,
> + "vhost-net",
> + &vhost_net_fops,
> +};
> +
> +int vhost_net_init(void)
> +{
> + int r = vhost_init();
> + if (r)
> + goto err_init;
> + r = misc_register(&vhost_net_misc);
> + if (r)
> + goto err_reg;
> + return 0;
> +err_reg:
> + vhost_cleanup();
> +err_init:
> + return r;
> +
> +}
> +module_init(vhost_net_init);
> +
> +void vhost_net_exit(void)
> +{
> + misc_deregister(&vhost_net_misc);
> + vhost_cleanup();
> +}
> +module_exit(vhost_net_exit);
> +
> +MODULE_VERSION("0.0.1");
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Michael S. Tsirkin");
> +MODULE_DESCRIPTION("Host kernel accelerator for virtio net");
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> new file mode 100644
> index 0000000..6925cc1
> --- /dev/null
> +++ b/drivers/vhost/vhost.c
> @@ -0,0 +1,688 @@
> +/* Copyright (C) 2009 Red Hat, Inc.
> + * Copyright (C) 2006 Rusty Russell IBM Corporation
> + *
> + * Author: Michael S. Tsirkin <mst(a)redhat.com>
> + *
> + * Inspiration, some code, and most witty comments come from
> + * Documentation/lguest/lguest.c, by Rusty Russell
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.
> + *
> + * Generic code for virtio server in host kernel.
> + */
> +
> +#include <linux/eventfd.h>
> +#include <linux/vhost.h>
> +#include <linux/virtio_net.h>
> +#include <linux/mm.h>
> +#include <linux/miscdevice.h>
> +#include <linux/mutex.h>
> +#include <linux/workqueue.h>
> +#include <linux/rcupdate.h>
> +#include <linux/poll.h>
> +#include <linux/file.h>
> +
> +#include <linux/net.h>
> +#include <linux/if_packet.h>
> +#include <linux/if_arp.h>
> +
> +#include <net/sock.h>
> +
> +#include "vhost.h"
> +
> +enum {
> + VHOST_MEMORY_MAX_NREGIONS = 64,
> +};
> +
> +static struct workqueue_struct *vhost_workqueue;
> +
> +static void vhost_poll_func(struct file *file, wait_queue_head_t *wqh,
> + poll_table *pt)
> +{
> + struct vhost_poll *poll;
> + poll = container_of(pt, struct vhost_poll, table);
> +
> + poll->wqh = wqh;
> + add_wait_queue(wqh, &poll->wait);
> +}
> +
> +static int vhost_poll_wakeup(wait_queue_t *wait, unsigned mode, int sync,
> + void *key)
> +{
> + struct vhost_poll *poll;
> + poll = container_of(wait, struct vhost_poll, wait);
> + if (!((unsigned long)key & poll->mask))
> + return 0;
> +
> + queue_work(vhost_workqueue, &poll->work);
> + return 0;
> +}
> +
> +/* Init poll structure */
> +void vhost_poll_init(struct vhost_poll *poll, work_func_t func,
> + unsigned long mask)
> +{
> + INIT_WORK(&poll->work, func);
> + init_waitqueue_func_entry(&poll->wait, vhost_poll_wakeup);
> + init_poll_funcptr(&poll->table, vhost_poll_func);
> + poll->mask = mask;
> +}
> +
> +/* Start polling a file. We add ourselves to file's wait queue. The caller must
> + * keep a reference to a file until after vhost_poll_stop is called. */
> +void vhost_poll_start(struct vhost_poll *poll, struct file *file)
> +{
> + unsigned long mask;
> + mask = file->f_op->poll(file, &poll->table);
> + if (mask)
> + vhost_poll_wakeup(&poll->wait, 0, 0, (void *)mask);
> +}
> +
> +/* Stop polling a file. After this function returns, it becomes safe to drop the
> + * file reference. You must also flush afterwards. */
> +void vhost_poll_stop(struct vhost_poll *poll)
> +{
> + remove_wait_queue(poll->wqh, &poll->wait);
> +}
> +
> +/* Flush any work that has been scheduled. When calling this, don't hold any
> + * locks that are also used by the callback. */
> +void vhost_poll_flush(struct vhost_poll *poll)
> +{
> + flush_work(&poll->work);
> +}
> +
> +long vhost_dev_init(struct vhost_dev *dev,
> + struct vhost_virtqueue *vqs, int nvqs)
> +{
> + int i;
> + dev->vqs = vqs;
> + dev->nvqs = nvqs;
> + mutex_init(&dev->mutex);
> +
> + for (i = 0; i < dev->nvqs; ++i) {
> + dev->vqs[i].dev = dev;
> + mutex_init(&dev->vqs[i].mutex);
> + if (dev->vqs[i].handle_kick)
> + vhost_poll_init(&dev->vqs[i].poll,
> + dev->vqs[i].handle_kick,
> + POLLIN);
> + }
> + return 0;
> +}
> +
> +/* Caller should have device mutex */
> +long vhost_dev_check_owner(struct vhost_dev *dev)
> +{
> + /* Are you the owner? If not, I don't think you mean to do that */
> + return dev->mm == current->mm ? 0 : -EPERM;
> +}
> +
> +/* Caller should have device mutex */
> +static long vhost_dev_set_owner(struct vhost_dev *dev)
> +{
> + /* Is there an owner already? */
> + if (dev->mm)
> + return -EBUSY;
> + /* No owner, become one */
> + dev->mm = get_task_mm(current);
> + return 0;
> +}
> +
> +/* Caller should have device mutex */
> +long vhost_dev_reset_owner(struct vhost_dev *dev)
> +{
> + struct vhost_memory *memory;
> +
> + /* Restore memory to default 1:1 mapping. */
> + memory = kmalloc(offsetof(struct vhost_memory, regions) +
> + 2 * sizeof *memory->regions, GFP_KERNEL);
> + if (!memory)
> + return -ENOMEM;
> +
> + vhost_dev_cleanup(dev);
> +
> + memory->nregions = 2;
> + memory->regions[0].guest_phys_addr = 1;
> + memory->regions[0].userspace_addr = 1;
> + memory->regions[0].memory_size = ~0ULL;
> + memory->regions[1].guest_phys_addr = 0;
> + memory->regions[1].userspace_addr = 0;
> + memory->regions[1].memory_size = 1;
> + dev->memory = memory;
> + return 0;
> +}
> +
> +/* Caller should have device mutex */
> +void vhost_dev_cleanup(struct vhost_dev *dev)
> +{
> + int i;
> + for (i = 0; i < dev->nvqs; ++i) {
> + if (dev->vqs[i].kick && dev->vqs[i].handle_kick) {
> + vhost_poll_stop(&dev->vqs[i].poll);
> + vhost_poll_flush(&dev->vqs[i].poll);
> + }
> + if (dev->vqs[i].error_ctx)
> + eventfd_ctx_put(dev->vqs[i].error_ctx);
> + if (dev->vqs[i].error)
> + fput(dev->vqs[i].error);
> + if (dev->vqs[i].kick)
> + fput(dev->vqs[i].kick);
> + if (dev->vqs[i].call_ctx)
> + eventfd_ctx_put(dev->vqs[i].call_ctx);
> + if (dev->vqs[i].call)
> + fput(dev->vqs[i].call);
> + dev->vqs[i].error_ctx = NULL;
> + dev->vqs[i].error = NULL;
> + dev->vqs[i].kick = NULL;
> + dev->vqs[i].call_ctx = NULL;
> + dev->vqs[i].call = NULL;
> + }
> + /* No one will access memory at this point */
> + kfree(dev->memory);
> + dev->memory = NULL;
> + if (dev->mm)
> + mmput(dev->mm);
> + dev->mm = NULL;
> +}
> +
> +static long vhost_set_memory(struct vhost_dev *d, struct vhost_memory __user *m)
> +{
> + struct vhost_memory mem, *newmem, *oldmem;
> + unsigned long size = offsetof(struct vhost_memory, regions);
> + long r;
> + r = copy_from_user(&mem, m, size);
> + if (r)
> + return r;
> + if (mem.padding)
> + return -EOPNOTSUPP;
> + if (mem.nregions > VHOST_MEMORY_MAX_NREGIONS)
> + return -E2BIG;
> + newmem = kmalloc(size + mem.nregions * sizeof *m->regions, GFP_KERNEL);
> + if (!newmem)
> + return -ENOMEM;
> +
> + memcpy(newmem, &mem, size);
> + r = copy_from_user(newmem->regions, m->regions,
> + mem.nregions * sizeof *m->regions);
> + if (r) {
> + kfree(newmem);
> + return r;
> + }
> + oldmem = d->memory;
> + rcu_assign_pointer(d->memory, newmem);
> + synchronize_rcu();
> + kfree(oldmem);
> + return 0;
> +}
> +
> +static int init_used(struct vhost_virtqueue *vq)
> +{
> + int r = put_user(vq->used_flags, &vq->used->flags);
> + if (r)
> + return r;
> + return get_user(vq->last_used_idx, &vq->used->idx);
> +}
> +
> +static long vhost_set_vring(struct vhost_dev *d, int ioctl, void __user *argp)
> +{
> + struct file *eventfp, *filep = NULL,
> + *pollstart = NULL, *pollstop = NULL;
> + struct eventfd_ctx *ctx = NULL;
> + u32 __user *idxp = argp;
> + struct vhost_virtqueue *vq;
> + struct vhost_vring_state s;
> + struct vhost_vring_file f;
> + struct vhost_vring_addr a;
> + u32 idx;
> + long r;
> +
> + r = get_user(idx, idxp);
> + if (r < 0)
> + return r;
> + if (idx > d->nvqs)
> + return -ENOBUFS;
> +
> + vq = d->vqs + idx;
> +
> + mutex_lock(&vq->mutex);
> +
> + switch (ioctl) {
> + case VHOST_SET_VRING_NUM:
> + r = copy_from_user(&s, argp, sizeof s);
> + if (r < 0)
> + break;
> + if (s.num > 0xffff) {
> + r = -EINVAL;
> + break;
> + }
> + vq->num = s.num;
> + break;
> + case VHOST_SET_VRING_BASE:
> + r = copy_from_user(&s, argp, sizeof s);
> + if (r < 0)
> + break;
> + if (s.num > 0xffff) {
> + r = -EINVAL;
> + break;
> + }
> + vq->avail_idx = vq->last_avail_idx = s.num;
> + break;
> + case VHOST_GET_VRING_BASE:
> + s.index = idx;
> + s.num = vq->last_avail_idx;
> + r = copy_to_user(argp, &s, sizeof s);
> + break;
> + case VHOST_SET_VRING_DESC:
> + r = copy_from_user(&a, argp, sizeof a);
> + if (r < 0)
> + break;
> + if (a.padding) {
> + r = -EOPNOTSUPP;
> + break;
> + }
> + if ((u64)(long)a.user_addr != a.user_addr) {
> + r = -EFAULT;
> + break;
> + }
> + vq->desc = (void __user *)(long)a.user_addr;
> + break;
> + case VHOST_SET_VRING_AVAIL:
> + r = copy_from_user(&a, argp, sizeof a);
> + if (r < 0)
> + break;
> + if (a.padding) {
> + r = -EOPNOTSUPP;
> + break;
> + }
> + if ((u64)(long)a.user_addr != a.user_addr) {
> + r = -EFAULT;
> + break;
> + }
> + vq->avail = (void __user *)(long)a.user_addr;
> + /* Forget the cached index value. */
> + vq->avail_idx = vq->last_avail_idx;
> + break;
> + case VHOST_SET_VRING_USED:
> + r = copy_from_user(&a, argp, sizeof a);
> + if (r < 0)
> + break;
> + if (a.padding) {
> + r = -EOPNOTSUPP;
> + break;
> + }
> + if ((u64)(long)a.user_addr != a.user_addr) {
> + r = -EFAULT;
> + break;
> + }
> + vq->used = (void __user *)(long)a.user_addr;
> + r = init_used(vq);
> + if (r)
> + break;
> + break;
> + case VHOST_SET_VRING_KICK:
> + r = copy_from_user(&f, argp, sizeof f);
> + if (r < 0)
> + break;
> + eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
> + if (IS_ERR(eventfp))
> + return PTR_ERR(eventfp);
> + if (eventfp != vq->kick) {
> + pollstop = filep = vq->kick;
> + pollstart = vq->kick = eventfp;
> + } else
> + filep = eventfp;
> + break;
> + case VHOST_SET_VRING_CALL:
> + r = copy_from_user(&f, argp, sizeof f);
> + if (r < 0)
> + break;
> + eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
> + if (IS_ERR(eventfp))
> + return PTR_ERR(eventfp);
> + if (eventfp != vq->call) {
> + filep = vq->call;
> + ctx = vq->call_ctx;
> + vq->call = eventfp;
> + vq->call_ctx = eventfp ?
> + eventfd_ctx_fileget(eventfp) : NULL;
> + } else
> + filep = eventfp;
> + break;
> + case VHOST_SET_VRING_ERR:
> + r = copy_from_user(&f, argp, sizeof f);
> + if (r < 0)
> + break;
> + eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
> + if (IS_ERR(eventfp))
> + return PTR_ERR(eventfp);
> + if (eventfp != vq->error) {
> + filep = vq->error;
> + vq->error = eventfp;
> + ctx = vq->error_ctx;
> + vq->error_ctx = eventfp ?
> + eventfd_ctx_fileget(eventfp) : NULL;
> + } else
> + filep = eventfp;
> + break;

I'm not sure how these eventfd's save a trip to userspace.

AFAICT, eventfd's cannot be used to signal another part of the kernel,
they can only be used to wake up userspace.

In my system, when an IRQ for kick() comes in, I have an eventfd which
gets signalled to notify userspace. When I want to send a call(), I have
to use a special ioctl(), just like lguest does.

Doesn't this mean that for call(), vhost is just going to signal an
eventfd to wake up userspace, which is then going to call ioctl(), and
then we're back in kernelspace. Seems like a wasted userspace
round-trip.

Or am I mis-reading this code?

PS - you can see my current code at:
http://www.mmarray.org/~iws/virtio-phys/

Thanks,
Ira

> + default:
> + r = -ENOIOCTLCMD;
> + }
> +
> + if (pollstop && vq->handle_kick)
> + vhost_poll_stop(&vq->poll);
> +
> + if (ctx)
> + eventfd_ctx_put(ctx);
> + if (filep)
> + fput(filep);
> +
> + if (pollstart && vq->handle_kick)
> + vhost_poll_start(&vq->poll, vq->kick);
> +
> + mutex_unlock(&vq->mutex);
> +
> + if (pollstop && vq->handle_kick)
> + vhost_poll_flush(&vq->poll);
> + return 0;
> +}
> +
> +long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + long r;
> +
> + mutex_lock(&d->mutex);
> + /* If you are not the owner, you can become one */
> + if (ioctl == VHOST_SET_OWNER) {
> + r = vhost_dev_set_owner(d);
> + goto done;
> + }
> +
> + /* You must be the owner to do anything else */
> + r = vhost_dev_check_owner(d);
> + if (r)
> + goto done;
> +
> + switch (ioctl) {
> + case VHOST_SET_MEM_TABLE:
> + r = vhost_set_memory(d, argp);
> + break;
> + default:
> + r = vhost_set_vring(d, ioctl, argp);
> + break;
> + }
> +done:
> + mutex_unlock(&d->mutex);
> + return r;
> +}
> +
> +static const struct vhost_memory_region *find_region(struct vhost_memory *mem,
> + __u64 addr, __u32 len)
> +{
> + struct vhost_memory_region *reg;
> + int i;
> + /* linear search is not brilliant, but we really have on the order of 6
> + * regions in practice */
> + for (i = 0; i < mem->nregions; ++i) {
> + reg = mem->regions + i;
> + if (reg->guest_phys_addr <= addr &&
> + reg->guest_phys_addr + reg->memory_size - 1 >= addr)
> + return reg;
> + }
> + return NULL;
> +}
> +
> +int translate_desc(struct vhost_dev *dev, u64 addr, u32 len,
> + struct iovec iov[], int iov_size)
> +{
> + const struct vhost_memory_region *reg;
> + struct vhost_memory *mem;
> + struct iovec *_iov;
> + u64 s = 0;
> + int ret = 0;
> +
> + rcu_read_lock();
> +
> + mem = rcu_dereference(dev->memory);
> + while ((u64)len > s) {
> + u64 size;
> + if (ret >= iov_size) {
> + ret = -ENOBUFS;
> + break;
> + }
> + reg = find_region(mem, addr, len);
> + if (!reg) {
> + ret = -EFAULT;
> + break;
> + }
> + _iov = iov + ret;
> + size = reg->memory_size - addr + reg->guest_phys_addr;
> + _iov->iov_len = min((u64)len, size);
> + _iov->iov_base = (void *)
> + (reg->userspace_addr + addr - reg->guest_phys_addr);
> + s += size;
> + addr += size;
> + ++ret;
> + }
> +
> + rcu_read_unlock();
> + return ret;
> +}
> +
> +/* Each buffer in the virtqueues is actually a chain of descriptors. This
> + * function returns the next descriptor in the chain, or vq->vring.num if we're
> + * at the end. */
> +static unsigned next_desc(struct vhost_virtqueue *vq, struct vring_desc *desc)
> +{
> + unsigned int next;
> +
> + /* If this descriptor says it doesn't chain, we're done. */
> + if (!(desc->flags & VRING_DESC_F_NEXT))
> + return vq->num;
> +
> + /* Check they're not leading us off end of descriptors. */
> + next = desc->next;
> + /* Make sure compiler knows to grab that: we don't want it changing! */
> + /* We will use the result as an index in an array, so most
> + * architectures only need a compiler barrier here. */
> + read_barrier_depends();
> +
> + if (next >= vq->num) {
> + vq_err(vq, "Desc next is %u > %u", next, vq->num);
> + return vq->num;
> + }
> +
> + return next;
> +}
> +
> +/* This looks in the virtqueue and for the first available buffer, and converts
> + * it to an iovec for convenient access. Since descriptors consist of some
> + * number of output then some number of input descriptors, it's actually two
> + * iovecs, but we pack them into one and note how many of each there were.
> + *
> + * This function returns the descriptor number found, or vq->num (which
> + * is never a valid descriptor number) if none was found. */
> +unsigned vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
> + struct iovec iov[],
> + unsigned int *out_num, unsigned int *in_num)
> +{
> + struct vring_desc desc;
> + unsigned int i, head;
> + u16 last_avail_idx;
> + int ret;
> +
> + /* Check it isn't doing very strange things with descriptor numbers. */
> + last_avail_idx = vq->last_avail_idx;
> + if (get_user(vq->avail_idx, &vq->avail->idx)) {
> + vq_err(vq, "Failed to access avail idx at %p\n",
> + &vq->avail->idx);
> + return vq->num;
> + }
> +
> + if ((u16)(vq->avail_idx - last_avail_idx) > vq->num) {
> + vq_err(vq, "Guest moved used index from %u to %u",
> + last_avail_idx, vq->avail_idx);
> + return vq->num;
> + }
> +
> + /* If there's nothing new since last we looked, return invalid. */
> + if (vq->avail_idx == last_avail_idx)
> + return vq->num;
> +
> + /* Grab the next descriptor number they're advertising, and increment
> + * the index we've seen. */
> + if (get_user(head, &vq->avail->ring[last_avail_idx % vq->num])) {
> + vq_err(vq, "Failed to read head: idx %d address %p\n",
> + last_avail_idx,
> + &vq->avail->ring[last_avail_idx % vq->num]);
> + return vq->num;
> + }
> +
> + /* If their number is silly, that's an error. */
> + if (head >= vq->num) {
> + vq_err(vq, "Guest says index %u > %u is available",
> + head, vq->num);
> + return vq->num;
> + }
> +
> + vq->last_avail_idx++;
> +
> + /* When we start there are none of either input nor output. */
> + *out_num = *in_num = 0;
> +
> + i = head;
> + do {
> + unsigned iov_count = *in_num + *out_num;
> + if (copy_from_user(&desc, vq->desc + i, sizeof desc)) {
> + vq_err(vq, "Failed to get descriptor: idx %d addr %p\n",
> + i, vq->desc + i);
> + return vq->num;
> + }
> + ret = translate_desc(dev, desc.addr, desc.len, iov + iov_count,
> + VHOST_NET_MAX_SG - iov_count);
> + if (ret < 0) {
> + vq_err(vq, "Translation failure %d descriptor idx %d\n",
> + ret, i);
> + return vq->num;
> + }
> + /* If this is an input descriptor, increment that count. */
> + if (desc.flags & VRING_DESC_F_WRITE)
> + *in_num += ret;
> + else {
> + /* If it's an output descriptor, they're all supposed
> + * to come before any input descriptors. */
> + if (*in_num) {
> + vq_err(vq, "Descriptor has out after in: "
> + "idx %d\n", i);
> + return vq->num;
> + }
> + *out_num += ret;
> + }
> + } while ((i = next_desc(vq, &desc)) != vq->num);
> + return head;
> +}
> +
> +/* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */
> +void vhost_discard_vq_desc(struct vhost_virtqueue *vq)
> +{
> + vq->last_avail_idx--;
> +}
> +
> +/* After we've used one of their buffers, we tell them about it. We'll then
> + * want to send them an interrupt, using vq->call. */
> +int vhost_add_used(struct vhost_virtqueue *vq,
> + unsigned int head, int len)
> +{
> + struct vring_used_elem *used;
> +
> + /* The virtqueue contains a ring of used buffers. Get a pointer to the
> + * next entry in that used ring. */
> + used = &vq->used->ring[vq->last_used_idx % vq->num];
> + if (put_user(head, &used->id)) {
> + vq_err(vq, "Failed to write used id");
> + return -EFAULT;
> + }
> + if (put_user(len, &used->len)) {
> + vq_err(vq, "Failed to write used len");
> + return -EFAULT;
> + }
> + /* Make sure buffer is written before we update index. */
> + wmb();
> + if (put_user(vq->last_used_idx + 1, &vq->used->idx)) {
> + vq_err(vq, "Failed to increment used idx");
> + return -EFAULT;
> + }
> + vq->last_used_idx++;
> + return 0;
> +}
> +
> +/* This actually sends the interrupt for this virtqueue */
> +void vhost_trigger_irq(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> +{
> + __u16 flags = 0;
> + if (get_user(flags, &vq->avail->flags)) {
> + vq_err(vq, "Failed to get flags");
> + return;
> + }
> +
> + /* If they don't want an interrupt, don't send one, unless empty. */
> + if ((flags & VRING_AVAIL_F_NO_INTERRUPT) &&
> + (!vhost_has_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY) ||
> + vq->avail_idx != vq->last_avail_idx))
> + return;
> +
> + /* Send the Guest an interrupt tell them we used something up. */
> + if (vq->call_ctx)
> + eventfd_signal(vq->call_ctx, 1);
> +}
> +
> +/* And here's the combo meal deal. Supersize me! */
> +void vhost_add_used_and_trigger(struct vhost_dev *dev,
> + struct vhost_virtqueue *vq,
> + unsigned int head, int len)
> +{
> + vhost_add_used(vq, head, len);
> + vhost_trigger_irq(dev, vq);
> +}
> +
> +/* OK, now we need to know about added descriptors. */
> +bool vhost_notify(struct vhost_virtqueue *vq)
> +{
> + int r;
> + if (!(vq->used_flags & VRING_USED_F_NO_NOTIFY))
> + return false;
> + vq->used_flags &= ~VRING_USED_F_NO_NOTIFY;
> + r = put_user(vq->used_flags, &vq->used->flags);
> + if (r)
> + vq_err(vq, "Failed to disable notification: %d\n", r);
> + /* They could have slipped one in as we were doing that: make
> + * sure it's written, tell caller it needs to check again. */
> + mb();
> + return true;
> +}
> +
> +/* We don't need to be notified again. */
> +void vhost_no_notify(struct vhost_virtqueue *vq)
> +{
> + int r;
> + if (vq->used_flags & VRING_USED_F_NO_NOTIFY)
> + return;
> + vq->used_flags |= VRING_USED_F_NO_NOTIFY;
> + r = put_user(vq->used_flags, &vq->used->flags);
> + if (r)
> + vq_err(vq, "Failed to enable notification: %d\n", r);
> +}
> +
> +int vhost_init(void)
> +{
> + vhost_workqueue = create_workqueue("vhost");
> + if (!vhost_workqueue)
> + return -ENOMEM;
> + return 0;
> +}
> +
> +void vhost_cleanup(void)
> +{
> + destroy_workqueue(vhost_workqueue);
> +}
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> new file mode 100644
> index 0000000..8e13d06
> --- /dev/null
> +++ b/drivers/vhost/vhost.h
> @@ -0,0 +1,122 @@
> +#ifndef _VHOST_H
> +#define _VHOST_H
> +
> +#include <linux/eventfd.h>
> +#include <linux/vhost.h>
> +#include <linux/mm.h>
> +#include <linux/mutex.h>
> +#include <linux/workqueue.h>
> +#include <linux/poll.h>
> +#include <linux/file.h>
> +#include <linux/skbuff.h>
> +#include <linux/uio.h>
> +#include <linux/virtio_config.h>
> +
> +struct vhost_device;
> +
> +enum {
> + VHOST_NET_MAX_SG = MAX_SKB_FRAGS + 2,
> +};
> +
> +/* Poll a file (eventfd or socket) */
> +/* Note: there's nothing vhost specific about this structure. */
> +struct vhost_poll {
> + poll_table table;
> + wait_queue_head_t *wqh;
> + wait_queue_t wait;
> + /* struct which will handle all actual work. */
> + struct work_struct work;
> + unsigned long mask;
> +};
> +
> +void vhost_poll_init(struct vhost_poll *poll, work_func_t func,
> + unsigned long mask);
> +void vhost_poll_start(struct vhost_poll *poll, struct file *file);
> +void vhost_poll_stop(struct vhost_poll *poll);
> +void vhost_poll_flush(struct vhost_poll *poll);
> +
> +/* The virtqueue structure describes a queue attached to a device. */
> +struct vhost_virtqueue {
> + struct vhost_dev *dev;
> +
> + /* The actual ring of buffers. */
> + struct mutex mutex;
> + unsigned int num;
> + struct vring_desc __user *desc;
> + struct vring_avail __user *avail;
> + struct vring_used __user *used;
> + struct file *kick;
> + struct file *call;
> + struct file *error;
> + struct eventfd_ctx *call_ctx;
> + struct eventfd_ctx *error_ctx;
> +
> + struct vhost_poll poll;
> +
> + /* The routine to call when the Guest pings us, or timeout. */
> + work_func_t handle_kick;
> +
> + /* Last available index we saw. */
> + u16 last_avail_idx;
> +
> + /* Caches available index value from user. */
> + u16 avail_idx;
> +
> + /* Last index we used. */
> + u16 last_used_idx;
> +
> + /* Used flags */
> + u16 used_flags;
> +
> + struct iovec iov[VHOST_NET_MAX_SG];
> + struct iovec hdr[VHOST_NET_MAX_SG];
> +};
> +
> +struct vhost_dev {
> + /* Readers use RCU to access memory table pointer.
> + * Writers use mutex below.*/
> + struct vhost_memory *memory;
> + struct mm_struct *mm;
> + struct vhost_virtqueue *vqs;
> + int nvqs;
> + struct mutex mutex;
> + unsigned acked_features;
> +};
> +
> +long vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue *vqs, int nvqs);
> +long vhost_dev_check_owner(struct vhost_dev *);
> +long vhost_dev_reset_owner(struct vhost_dev *);
> +void vhost_dev_cleanup(struct vhost_dev *);
> +long vhost_dev_ioctl(struct vhost_dev *, unsigned int ioctl, unsigned long arg);
> +
> +unsigned vhost_get_vq_desc(struct vhost_dev *, struct vhost_virtqueue *,
> + struct iovec iov[],
> + unsigned int *out_num, unsigned int *in_num);
> +void vhost_discard_vq_desc(struct vhost_virtqueue *);
> +
> +int vhost_add_used(struct vhost_virtqueue *, unsigned int head, int len);
> +void vhost_trigger_irq(struct vhost_dev *, struct vhost_virtqueue *);
> +void vhost_add_used_and_trigger(struct vhost_dev *, struct vhost_virtqueue *,
> + unsigned int head, int len);
> +void vhost_no_notify(struct vhost_virtqueue *);
> +bool vhost_notify(struct vhost_virtqueue *);
> +
> +int vhost_init(void);
> +void vhost_cleanup(void);
> +
> +#define vq_err(vq, fmt, ...) do { \
> + pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> + if ((vq)->error_ctx) \
> + eventfd_signal((vq)->error_ctx, 1);\
> + } while (0)
> +
> +enum {
> + VHOST_FEATURES = 1 << VIRTIO_F_NOTIFY_ON_EMPTY,
> +};
> +
> +static inline int vhost_has_feature(struct vhost_dev *dev, int bit)
> +{
> + return dev->acked_features & (1 << bit);
> +}
> +
> +#endif
> diff --git a/include/linux/Kbuild b/include/linux/Kbuild
> index dec2f18..975df9a 100644
> --- a/include/linux/Kbuild
> +++ b/include/linux/Kbuild
> @@ -360,6 +360,7 @@ unifdef-y += uio.h
> unifdef-y += unistd.h
> unifdef-y += usbdevice_fs.h
> unifdef-y += utsname.h
> +unifdef-y += vhost.h
> unifdef-y += videodev2.h
> unifdef-y += videodev.h
> unifdef-y += virtio_config.h
> diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
> index 0521177..781a8bb 100644
> --- a/include/linux/miscdevice.h
> +++ b/include/linux/miscdevice.h
> @@ -30,6 +30,7 @@
> #define HPET_MINOR 228
> #define FUSE_MINOR 229
> #define KVM_MINOR 232
> +#define VHOST_NET_MINOR 233
> #define MISC_DYNAMIC_MINOR 255
>
> struct device;
> diff --git a/include/linux/vhost.h b/include/linux/vhost.h
> new file mode 100644
> index 0000000..3f441a9
> --- /dev/null
> +++ b/include/linux/vhost.h
> @@ -0,0 +1,101 @@
> +#ifndef _LINUX_VHOST_H
> +#define _LINUX_VHOST_H
> +/* Userspace interface for in-kernel virtio accelerators. */
> +
> +/* vhost is used to reduce the number of system calls involved in virtio.
> + *
> + * Existing virtio net code is used in the guest without modification.
> + *
> + * This header includes interface used by userspace hypervisor for
> + * device configuration.
> + */
> +
> +#include <linux/types.h>
> +#include <linux/compiler.h>
> +#include <linux/ioctl.h>
> +#include <linux/virtio_config.h>
> +#include <linux/virtio_ring.h>
> +
> +struct vhost_vring_state {
> + unsigned int index;
> + unsigned int num;
> +};
> +
> +struct vhost_vring_file {
> + unsigned int index;
> + int fd;
> +};
> +
> +struct vhost_vring_addr {
> + unsigned int index;
> + unsigned int padding;
> + __u64 user_addr;
> +};
> +
> +struct vhost_memory_region {
> + __u64 guest_phys_addr;
> + __u64 memory_size; /* bytes */
> + __u64 userspace_addr;
> + __u64 padding; /* read/write protection? */
> +};
> +
> +struct vhost_memory {
> + __u32 nregions;
> + __u32 padding;
> + struct vhost_memory_region regions[0];
> +};
> +
> +/* ioctls */
> +
> +#define VHOST_VIRTIO 0xAF
> +
> +/* Features bitmask for forward compatibility. Transport bits are used for
> + * vhost specific features. */
> +#define VHOST_GET_FEATURES _IOR(VHOST_VIRTIO, 0x00, __u64)
> +#define VHOST_ACK_FEATURES _IOW(VHOST_VIRTIO, 0x00, __u64)
> +
> +/* Set current process as the (exclusive) owner of this file descriptor. This
> + * must be called before any other vhost command. Further calls to
> + * VHOST_OWNER_SET fail until VHOST_OWNER_RESET is called. */
> +#define VHOST_SET_OWNER _IO(VHOST_VIRTIO, 0x01)
> +/* Give up ownership, and reset the device to default values.
> + * Allows subsequent call to VHOST_OWNER_SET to succeed. */
> +#define VHOST_RESET_OWNER _IO(VHOST_VIRTIO, 0x02)
> +
> +/* Set up/modify memory layout */
> +#define VHOST_SET_MEM_TABLE _IOW(VHOST_VIRTIO, 0x03, struct vhost_memory)
> +
> +/* Ring setup. These parameters can not be modified while ring is running
> + * (bound to a device). */
> +/* Set number of descriptors in ring */
> +#define VHOST_SET_VRING_NUM _IOW(VHOST_VIRTIO, 0x10, struct vhost_vring_state)
> +/* Start of array of descriptors (virtually contiguous) */
> +#define VHOST_SET_VRING_DESC _IOW(VHOST_VIRTIO, 0x11, struct vhost_vring_addr)
> +/* Used structure address */
> +#define VHOST_SET_VRING_USED _IOW(VHOST_VIRTIO, 0x12, struct vhost_vring_addr)
> +/* Available structure address */
> +#define VHOST_SET_VRING_AVAIL _IOW(VHOST_VIRTIO, 0x13, struct vhost_vring_addr)
> +/* Base value where queue looks for available descriptors */
> +#define VHOST_SET_VRING_BASE _IOW(VHOST_VIRTIO, 0x14, struct vhost_vring_state)
> +/* Get accessor: reads index, writes value in num */
> +#define VHOST_GET_VRING_BASE _IOWR(VHOST_VIRTIO, 0x14, struct vhost_vring_state)
> +
> +/* The following ioctls use eventfd file descriptors to signal and poll
> + * for events. */
> +
> +/* Set eventfd to poll for added buffers */
> +#define VHOST_SET_VRING_KICK _IOW(VHOST_VIRTIO, 0x20, struct vhost_vring_file)
> +/* Set eventfd to signal when buffers have beed used */
> +#define VHOST_SET_VRING_CALL _IOW(VHOST_VIRTIO, 0x21, struct vhost_vring_file)
> +/* Set eventfd to signal an error */
> +#define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file)
> +
> +/* VHOST_NET specific defines */
> +
> +/* Attach virtio net device to a raw socket. The socket must be already
> + * bound to an ethernet device, this device will be used for transmit.
> + * Pass -1 to unbind from the socket and the transmit device.
> + * This can be used to stop the device (e.g. for migration). */
> +#define VHOST_NET_SET_SOCKET _IOW(VHOST_VIRTIO, 0x30, int)
> +
> +#endif
> --
> 1.6.2.5
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Gregory Haskins on 25 Sep 2009 17:40
Avi Kivity wrote:
> On 09/24/2009 09:03 PM, Gregory Haskins wrote:
>>
>>> I don't really see how vhost and vbus are different here. vhost expects
>>> signalling to happen through a couple of eventfds and requires someone
>>> to supply them and implement kernel support (if needed). vbus requires
>>> someone to write a connector to provide the signalling implementation.
>>> Neither will work out-of-the-box when implementing virtio-net over
>>> falling dominos, for example.
>>>
>> I realize in retrospect that my choice of words above implies vbus _is_
>> complete, but this is not what I was saying. What I was trying to
>> convey is that vbus is _more_ complete. Yes, in either case some kind
>> of glue needs to be written. The difference is that vbus implements
>> more of the glue generally, and leaves less required to be customized
>> for each iteration.
>>
>
>
> No argument there. Since you care about non-virt scenarios and virtio
> doesn't, naturally vbus is a better fit for them as the code stands.

Thanks for finally starting to acknowledge there's a benefit, at least.

To be more precise, IMO virtio is designed to be a performance oriented
ring-based driver interface that supports all types of hypervisors (e.g.
shmem based kvm, and non-shmem based Xen). vbus is designed to be a
high-performance generic shared-memory interconnect (for rings or
otherwise) framework for environments where linux is the underpinning
"host" (physical or virtual). They are distinctly different, but
complementary (the former addresses the part of the front-end, and
latter addresses the back-end, and a different part of the front-end).

In addition, the kvm-connector used in AlacrityVM's design strives to
add value and improve performance via other mechanisms, such as dynamic
allocation, interrupt coalescing (thus reducing exit-ratio, which is a
serious issue in KVM) and priortizable/nestable signals.

Today there is a large performance disparity between what a KVM guest
sees and what a native linux application sees on that same host. Just
take a look at some of my graphs between "virtio", and "native", for
example:

http://developer.novell.com/wiki/images/b/b7/31-rc4_throughput.png

A dominant vbus design principle is to try to achieve the same IO
performance for all "linux applications" whether they be literally
userspace applications, or things like KVM vcpus or Ira's physical
boards. It also aims to solve problems not previously expressible with
current technologies (even virtio), like nested real-time.

And even though you repeatedly insist otherwise, the neat thing here is
that the two technologies mesh (at least under certain circumstances,
like when virtio is deployed on a shared-memory friendly linux backend
like KVM). I hope that my stack diagram below depicts that clearly.


> But that's not a strong argument for vbus; instead of adding vbus you
> could make virtio more friendly to non-virt

Actually, it _is_ a strong argument then because adding vbus is what
helps makes virtio friendly to non-virt, at least for when performance
matters.

> (there's a limit how far you
> can take this, not imposed by the code, but by virtio's charter as a
> virtual device driver framework).
>
>> Going back to our stack diagrams, you could think of a vhost solution
>> like this:
>>
>> --------------------------
>> | virtio-net
>> --------------------------
>> | virtio-ring
>> --------------------------
>> | virtio-bus
>> --------------------------
>> | ? undefined-1 ?
>> --------------------------
>> | vhost
>> --------------------------
>>
>> and you could think of a vbus solution like this
>>
>> --------------------------
>> | virtio-net
>> --------------------------
>> | virtio-ring
>> --------------------------
>> | virtio-bus
>> --------------------------
>> | bus-interface
>> --------------------------
>> | ? undefined-2 ?
>> --------------------------
>> | bus-model
>> --------------------------
>> | virtio-net-device (vhost ported to vbus model? :)
>> --------------------------
>>
>>
>> So the difference between vhost and vbus in this particular context is
>> that you need to have "undefined-1" do device discovery/hotswap,
>> config-space, address-decode/isolation, signal-path routing, memory-path
>> routing, etc. Today this function is filled by things like virtio-pci,
>> pci-bus, KVM/ioeventfd, and QEMU for x86. I am not as familiar with
>> lguest, but presumably it is filled there by components like
>> virtio-lguest, lguest-bus, lguest.ko, and lguest-launcher. And to use
>> more contemporary examples, we might have virtio-domino, domino-bus,
>> domino.ko, and domino-launcher as well as virtio-ira, ira-bus, ira.ko,
>> and ira-launcher.
>>
>> Contrast this to the vbus stack: The bus-X components (when optionally
>> employed by the connector designer) do device-discovery, hotswap,
>> config-space, address-decode/isolation, signal-path and memory-path
>> routing, etc in a general (and pv-centric) way. The "undefined-2"
>> portion is the "connector", and just needs to convey messages like
>> "DEVCALL" and "SHMSIGNAL". The rest is handled in other parts of the
>> stack.
>>
>>
>
> Right. virtio assumes that it's in a virt scenario and that the guest
> architecture already has enumeration and hotplug mechanisms which it
> would prefer to use. That happens to be the case for kvm/x86.

No, virtio doesn't assume that. It's stack provides the "virtio-bus"
abstraction and what it does assume is that it will be wired up to
something underneath. Kvm/x86 conveniently has pci, so the virtio-pci
adapter was created to reuse much of that facility. For other things
like lguest and s360, something new had to be created underneath to make
up for the lack of pci-like support.

vbus, in conjunction with the kvm-connector, tries to unify that process
a little more by creating a PV-optimized bus. The idea is that it can
be reused in that situation instead of creating a new hypervisor
specific bus each time. It's also designed for high-performance, so you
get that important trait for free simply by tying into it.

>
>> So to answer your question, the difference is that the part that has to
>> be customized in vbus should be a fraction of what needs to be
>> customized with vhost because it defines more of the stack.
>
> But if you want to use the native mechanisms, vbus doesn't have any
> added value.

First of all, thats incorrect. If you want to use the "native"
mechanisms (via the way the vbus-connector is implemented, for instance)
you at least still have the benefit that the backend design is more
broadly re-useable in more environments (like non-virt, for instance),
because vbus does a proper job of defining the requisite
layers/abstractions compared to vhost. So it adds value even in that
situation.

Second of all, with PV there is no such thing as "native". It's
software so it can be whatever we want. Sure, you could argue that the
guest may have built-in support for something like PCI protocol.
However, PCI protocol itself isn't suitable for high-performance PV out
of the can. So you will therefore invariably require new software
layers on top anyway, even if part of the support is already included.

And lastly, why would you _need_ to use the so called "native"
mechanism? The short answer is, "you don't". Any given system (guest
or bare-metal) already have a wide-range of buses (try running "tree
/sys/bus" in Linux). More importantly, the concept of adding new buses
is widely supported in both the Windows and Linux driver model (and
probably any other guest-type that matters). Therefore, despite claims
to the contrary, its not hard or even unusual to add a new bus to the mix.

In summary, vbus is simply one more bus of many, purpose built to
support high-end IO in a virt-like model, giving controlled access to
the linux-host underneath it. You can write a high-performance layer
below the OS bus-model (vbus), or above it (virtio-pci) but either way
you are modifying the stack to add these capabilities, so we might as
well try to get this right.

With all due respect, you are making a big deal out of a minor issue.

>
>> And, as
>> eluded to in my diagram, both virtio-net and vhost (with some
>> modifications to fit into the vbus framework) are potentially
>> complementary, not competitors.
>>
>
> Only theoretically. The existing installed base would have to be thrown
> away

"Thrown away" is pure hyperbole. The installed base, worse case, needs
to load a new driver for a missing device. This is pretty much how
every machine works today, anyway. And if loading a driver was actually
some insurmountable hurdle, as its sometimes implied (but its not in
reality), you can alternatively make vbus look like a legacy bus if you
are willing to sacrifice some of features, like exit-ratio reduction and
priority.

FWIW: AlacrityVM isn't willing to sacrifice those features, so we will
provide a Linux and Windows driver for explicit bus support, as well as
open-specs and community development assistance to any other guest that
wants to add support in the future.

> or we'd need to support both.
>
>

No matter what model we talk about, there's always going to be a "both"
since the userspace virtio models are probably not going to go away (nor
should they).

>
>
>>> Without a vbus-connector-falling-dominos, vbus-venet can't do anything
>>> either.
>>>
>> Mostly covered above...
>>
>> However, I was addressing your assertion that vhost somehow magically
>> accomplishes this "container/addressing" function without any specific
>> kernel support. This is incorrect. I contend that this kernel support
>> is required and present. The difference is that its defined elsewhere
>> (and typically in a transport/arch specific way).
>>
>> IOW: You can basically think of the programmed PIO addresses as forming
>> its "container". Only addresses explicitly added are visible, and
>> everything else is inaccessible. This whole discussion is merely a
>> question of what's been generalized verses what needs to be
>> re-implemented each time.
>>
>
> Sorry, this is too abstract for me.

With all due respect, understanding my point above is required to have
any kind of meaningful discussion here.

>
>
>
>>> vbus doesn't do kvm guest address decoding for the fast path. It's
>>> still done by ioeventfd.
>>>
>> That is not correct. vbus does its own native address decoding in the
>> fast path, such as here:
>>
>> http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/client.c;h=e85b2d92d629734866496b67455dd307486e394a;hb=e6cbd4d1decca8e829db3b2b9b6ec65330b379e9#l331
>>
>>
>>
>
> All this is after kvm has decoded that vbus is addresses. It can't work
> without someone outside vbus deciding that.

How the connector message is delivered is really not relevant. Some
architectures will simply deliver the message point-to-point (like the
original hypercall design for KVM, or something like Ira's rig), and
some will need additional demuxing (like pci-bridge/pio based KVM).
It's an implementation detail of the connector.

However, the real point here is that something needs to establish a
scoped namespace mechanism, add items to that namespace, and advertise
the presence of the items to the guest. vbus has this facility built in
to its stack. vhost doesn't, so it must come from elsewhere.


>
>> In fact, it's actually a simpler design to unify things this way because
>> you avoid splitting the device model up. Consider how painful the vhost
>> implementation would be if it didn't already have the userspace
>> virtio-net to fall-back on. This is effectively what we face for new
>> devices going forward if that model is to persist.
>>
>
>
> It doesn't have just virtio-net, it has userspace-based hostplug

vbus has hotplug too: mkdir and rmdir

As an added bonus, its device-model is modular. A developer can write a
new device model, compile it, insmod it to the host kernel, hotplug it
to the running guest with mkdir/ln, and the come back out again
(hotunplug with rmdir, rmmod, etc). They may do this all without taking
the guest down, and while eating QEMU based IO solutions for breakfast
performance wise.

Afaict, qemu can't do either of those things.

> and a bunch of other devices impemented in userspace.

Thats fine. I am primarily interested in the high-performance
components, so most of those other items can stay there in userspace if
that is their ideal location.

> Currently qemu has
> virtio bindings for pci and syborg (whatever that is), and device models
> for baloon, block, net, and console, so it seems implementing device
> support in userspace is not as disasterous as you make it to be.

I intentionally qualified "device" with "new" in my statement. And in
that context I was talking about ultimately developing/supporting
in-kernel models, not pure legacy userspace ones. I have no doubt the
implementation of the original userpsace devices was not a difficult or
horrific endeavor.

Requiring new models to be implemented (at least) twice is a poor design
IMO, however. Requiring them to split such a minor portion of their
functionality (like read-only attributes) is a poor design, too. I have
already demonstrated there are other ways to achieve the same
high-performance goals without requiring two models developed/tested
each time and for each manager. For the times I went and tried to
satisfy your request in this manner, developing the code and managing
the resources in two places, for lack of a better description, made me
want to wretch. So I gave up, resolved that my original design was
better, and hoped that I could convince you and the community of the same.

>
>>> Invariably?
>>>
>> As in "always"
>>
>
> Refactor instead of duplicating.

There is no duplicating. vbus has no equivalent today as virtio doesn't
define these layers.

>
>>
>>> Use libraries (virtio-shmem.ko, libvhost.so).
>>>
>> What do you suppose vbus is? vbus-proxy.ko = virtio-shmem.ko, and you
>> dont need libvhost.so per se since you can just use standard kernel
>> interfaces (like configfs/sysfs). I could create an .so going forward
>> for the new ioctl-based interface, I suppose.
>>
>
> Refactor instead of rewriting.

There is no rewriting. vbus has no equivalent today as virtio doesn't
define these layers.

By your own admission, you said if you wanted that capability, use a
library. What I think you are not understanding is vbus _is_ that
library. So what is the problem, exactly?

>
>
>
>>> For kvm/x86 pci definitely remains king.
>>>
>> For full virtualization, sure. I agree. However, we are talking about
>> PV here. For PV, PCI is not a requirement and is a technical dead-end
>> IMO.
>>
>> KVM seems to be the only virt solution that thinks otherwise (*), but I
>> believe that is primarily a condition of its maturity. I aim to help
>> advance things here.
>>
>> (*) citation: xen has xenbus, lguest has lguest-bus, vmware has some
>> vmi-esq thing (I forget what its called) to name a few. Love 'em or
>> hate 'em, most other hypervisors do something along these lines. I'd
>> like to try to create one for KVM, but to unify them all (at least for
>> the Linux-based host designs).
>>
>
> VMware are throwing VMI away (won't be supported in their new product,
> and they've sent a patch to rip it off from Linux);

vmware only cares about x86 iiuc, so probably not a good example.

> Xen has to tunnel
> xenbus in pci for full virtualization (which is where Windows is, and
> where Linux will be too once people realize it's faster). lguest is
> meant as an example hypervisor, not an attempt to take over the world.

So pick any other hypervisor, and the situation is often similar.

>
> "PCI is a dead end" could not be more wrong, it's what guests support.

It's what _some_ guests support. Even for the guests that support it,
it's not well designed for PV. Therefore, you have to do a bunch of
dancing and waste resources on top to squeeze every last drop of
performance out of your platform. In addition, it has a bunch of
baggage that goes with it that is not necessary to do the job in a
software environment. It is therefore burdensome to recreate if you
don't already have something to leverage, like QEMU, just for the sake
of creating the illusion that its there.

Sounds pretty dead to me, sorry. We don't need it.

Alternatively, you can just try to set a stake in the ground for looking
forward and fixing those PV-specific problems hopefully once and for
all, like vbus and the kvm-connector tries to do. Sure, there will be
some degree of pain first as we roll out the subsystem and deploy
support, but thats true for lots of things. It's simply a platform
investment.


> An right now you can have a guest using pci to access a mix of
> userspace-emulated devices, userspace-emulated-but-kernel-accelerated
> virtio devices, and real host devices. All on one dead-end bus. Try
> that with vbus.

vbus is not interested in userspace devices. The charter is to provide
facilities for utilizing the host linux kernel's IO capabilities in the
most efficient, yet safe, manner possible. Those devices that fit
outside that charter can ride on legacy mechanisms if that suits them best.

>
>
>>>> I digress. My point here isn't PCI. The point here is the missing
>>>> component for when PCI is not present. The component that is partially
>>>> satisfied by vbus's devid addressing scheme. If you are going to use
>>>> vhost, and you don't have PCI, you've gotta build something to replace
>>>> it.
>>>>
>>>>
>>> Yes, that's why people have keyboards. They'll write that glue code if
>>> they need it. If it turns out to be a hit an people start having virtio
>>> transport module writing parties, they'll figure out a way to share
>>> code.
>>>
>> Sigh... The party has already started. I tried to invite you months
>> ago...
>>
>
> I've been voting virtio since 2007.

That doesn't have much to do with whats underneath it, since it doesn't
define these layers. See my stack diagram's for details.

>
>>> On the guest side, virtio-shmem.ko can unify the ring access. It
>>> probably makes sense even today. On the host side I eventfd is the
>>> kernel interface and libvhostconfig.so can provide the configuration
>>> when an existing ABI is not imposed.
>>>
>> That won't cut it. For one, creating an eventfd is only part of the
>> equation. I.e. you need to have originate/terminate somewhere
>> interesting (and in-kernel, otherwise use tuntap).
>>
>
> vbus needs the same thing so it cancels out.

No, it does not. vbus just needs a relatively simple single message
pipe between the guest and host (think "hypercall tunnel", if you will).
Per queue/device addressing is handled by the same conceptual namespace
as the one that would trigger eventfds in the model you mention. And
that namespace is built in to the vbus stack, and objects are registered
automatically as they are created.

Contrast that to vhost, which requires some other kernel interface to
exist, and to be managed manually for each object that is created. Your
libvhostconfig would need to somehow know how to perform this
registration operation, and there would have to be something in the
kernel to receive it, presumably on a per platform basis. Solving this
problem generally would probably end up looking eerily like vbus,
because thats what vbus does.

>
>>> Look at the virtio-net feature negotiation. There's a lot more there
>>> than the MAC address, and it's going to grow.
>>>
>> Agreed, but note that makes my point. That feature negotiation almost
>> invariably influences the device-model, not some config-space shim.
>> IOW: terminating config-space at some userspace shim is pointless. The
>> model ultimately needs the result of whatever transpires during that
>> negotiation anyway.
>>
>
> Well, let's see. Can vbus today:
>
> - let userspace know which features are available (so it can decide if
> live migration is possible)

yes, its in sysfs.

> - let userspace limit which features are exposed to the guest (so it can
> make live migration possible among hosts of different capabilities)

yes, its in sysfs.

> - let userspace know which features were negotiated (so it can transfer
> them to the other host during live migration)

no, but we can easily add ->save()/->restore() to the model going
forward, and the negotiated features are just a subcomponent if its
serialized stream.

> - let userspace tell the kernel which features were negotiated (when
> live migration completes, to avoid requiring the guest to re-negotiate)

that would be the function of the ->restore() deserializer.

> - do all that from an unprivileged process

yes, in the upcoming alacrityvm v0.3 with the ioctl based control plane.

> - securely wrt other unprivileged processes

yes, same mechanism plus it has a fork-inheritance model.

Bottom line: vbus isn't done, especially w.r.t. live-migration..but that
is not an valid argument against the idea if you believe in
release-early/release-often. kvm wasn't (isn't) done either when it was
proposed/merged.

Kind Regards,
-Greg

First  |  Prev  |  Next  |  Last
Pages: 3 4 5 6 7 8 9 10 11 12 13 14 15
Prev: bfa: Brocade BFA FC SCSI driver (bfad)
Next: Atheros Linux wireless drivers home page - and two new driver projects