qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 0/7] Vhost and vhost-net support for userspac


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v5 0/7] Vhost and vhost-net support for userspace based backends
Date: Fri, 10 Jan 2014 14:25:56 +0200

On Fri, Jan 10, 2014 at 11:58:23AM +0100, Antonios Motakis wrote:
> 
> 
> 
> On Thu, Jan 9, 2014 at 5:11 PM, Michael S. Tsirkin <address@hidden> wrote:
> 
>     On Thu, Jan 09, 2014 at 03:59:54PM +0100, Antonios Motakis wrote:
>     > In this patch series we would like to introduce our approach for putting
>     a
>     > virtio-net backend in an external userspace process. Our eventual target
>     is to
>     > run the network backend in the Snabbswitch ethernet switch, while
>     receiving
>     > traffic from a guest inside QEMU/KVM which runs an unmodified virtio-net
>     > implementation.
>     >
>     > For this, we are working into extending vhost to allow equivalent
>     functionality
>     > for userspace. Vhost already passes control of the data plane of
>     virtio-net to
>     > the host kernel; we want to realize a similar model, but for userspace.
>     >
>     > In this patch series the concept of a vhost-backend is introduced.
>     >
>     > We define two vhost backend types - vhost-kernel and vhost-user. The
>     former is
>     > the interface to the current kernel module implementation. Its control
>     plane is
>     > ioctl based. The data plane is the kernel directly accessing the QEMU
>     allocated,
>     > guest memory.
>     >
>     > In the new vhost-user backend, the control plane is based on
>     communication
>     > between QEMU and another userspace process using a unix domain socket.
>     This
>     > allows to implement a virtio backend for a guest running in QEMU, inside
>     the
>     > other userspace process.
>     >
>     > We change -mem-path to QemuOpts and add prealloc, share and unlink as
>     properties
>     > to it. HugeTLBFS requirements of -mem-path are relaxed, so any valid 
> path
>     can
>     > be used now. The new properties allow more fine grained control over the
>     guest
>     > RAM backing store.
>     >
>     > The data path is realized by directly accessing the vrings and the 
> buffer
>     data
>     > off the guest's memory.
>     >
>     > The current user of vhost-user is only vhost-net. We add new netdev
>     backend
>     > that is intended to initialize vhost-net with vhost-user backend.
>     >
>     > Example usage:
>     >
>     > qemu -m 1024 -mem-path /hugetlbfs,prealloc=on,share=on \
>     >      -netdev type=vhost-user,id=net0,file=/path/to/sock \
> 
> 
>     Why can't this use standard syntax that qemu_chr_open_socket
>     supports?
>     This will add features such as ability for management to open the socket
>     and pass it to qemu and switch, ability to switch server/client roles,
>     and others.
> 
> 
> What you have in mind is just to match the syntax used for the socket chardev,
> or are you proposing some code reuse or interaction with it?
>  

Matching syntax is most important IMHO.
But I'd say reusing code is a good idea too.


> 
> 
>     >      -device virtio-net-pci,netdev=net0
>     >
>     > Changes from v4:
>     >  - Use error_report for errors
>     >  - VhostUserMsg has new field 'size' indicating the following payload
>     length.
>     >    Field 'flags' now has version and reply bits. The structure is 
> packed.
>     >  - Send data is of variable length ('size' field in message)
>     >  - Parse received calls in 2 steps, header and payload
>     >  - Add new message type VHOST_USER_ECHO, to check connection status
>     >
>     > Changes from v3:
>     >  - Convert -mem-path to QemuOpts with prealloc, share and unlink
>     properties
>     >  - Set 1 sec timeout when read/write to the unix domain socket
>     >  - Fix file descriptor leak
>     >
>     > Changes from v2:
>     >  - Reconnect when the backend disappears
>     >
>     > Changes from v1:
>     >  - Implementation of vhost-user netdev backend
>     >  - Code improvements
>     >
>     > Antonios Motakis (7):
>     >   Convert -mem-path to QemuOpts and add prealloc,share and unlink
>     >     properties
>     >   Decouple vhost from kernel interface
>     >   Add vhost-user skeleton
>     >   Add domain socket communication for vhost-user backend
>     >   Add vhost-user calls implementation
>     >   Add new vhost-user netdev backend
>     >   Add vhost-user reconnection
>     >
>     >  exec.c                            |  57 ++++-
>     >  hmp-commands.hx                   |   4 +-
>     >  hw/net/vhost_net.c                | 144 ++++++++---
>     >  hw/net/virtio-net.c               |  42 ++--
>     >  hw/scsi/vhost-scsi.c              |  13 +-
>     >  hw/virtio/Makefile.objs           |   2 +-
>     >  hw/virtio/vhost-backend.c         | 504
>     ++++++++++++++++++++++++++++++++++++++
>     >  hw/virtio/vhost.c                 |  46 ++--
>     >  include/exec/cpu-all.h            |   3 -
>     >  include/hw/virtio/vhost-backend.h |  40 +++
>     >  include/hw/virtio/vhost.h         |   4 +-
>     >  include/net/vhost-user.h          |  17 ++
>     >  include/net/vhost_net.h           |  15 +-
>     >  net/Makefile.objs                 |   2 +-
>     >  net/clients.h                     |   3 +
>     >  net/hub.c                         |   1 +
>     >  net/net.c                         |   2 +
>     >  net/tap.c                         |  16 +-
>     >  net/vhost-user.c                  | 167 +++++++++++++
>     >  qapi-schema.json                  |  18 +-
>     >  qemu-options.hx                   |  13 +-
>     >  vl.c                              |  41 +++-
>     >  22 files changed, 1030 insertions(+), 124 deletions(-)
>     >  create mode 100644 hw/virtio/vhost-backend.c
>     >  create mode 100644 include/hw/virtio/vhost-backend.h
>     >  create mode 100644 include/net/vhost-user.h
>     >  create mode 100644 net/vhost-user.c
>     >
>     > --
>     > 1.8.3.2
>     >
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]