• Michael S. Tsirkin's avatar
    vhost_net: a kernel-level virtio server · 3a4d5c94
    Michael S. Tsirkin authored
    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, bug work-arounds in userspace)
    - write logging is supported (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 tap
    device.  Backend is also configured by userspace, including vlan/mac
    etc.
    
    Status: This works for me, and I haven't see any crashes.
    Compared to userspace, people reported improved latency (as I save up to
    4 system calls per packet), as well as better bandwidth and CPU
    utilization.
    
    Features that I plan to look at in the future:
    - mergeable buffers
    - zero copy
    - scalability tuning: figure out the best threading model to use
    
    Note on RCU usage (this is also documented in vhost.h, near
    private_pointer which is the value protected by this variant of RCU):
    what is happening is that the rcu_dereference() is being used in a
    workqueue item.  The role of rcu_read_lock() is taken on by the start of
    execution of the workqueue item, of rcu_read_unlock() by the end of
    execution of the workqueue item, and of synchronize_rcu() by
    flush_workqueue()/flush_work(). In the future we might need to apply
    some gcc attribute or sparse annotation to the function passed to
    INIT_WORK(). Paul's ack below is for this RCU usage.
    
    (Includes fixes by Alan Cox <alan@linux.intel.com>,
    David L Stevens <dlstevens@us.ibm.com>,
    Chris Wright <chrisw@redhat.com>)
    Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
    Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
    Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    3a4d5c94
Kconfig 430 Bytes