From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoCwt-0001Oq-BB for qemu-devel@nongnu.org; Wed, 04 Dec 2013 08:57:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoCwk-0006Bh-UO for qemu-devel@nongnu.org; Wed, 04 Dec 2013 08:57:07 -0500 Received: from mail-ea0-x236.google.com ([2a00:1450:4013:c01::236]:59914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoCwk-0006BX-NT for qemu-devel@nongnu.org; Wed, 04 Dec 2013 08:56:58 -0500 Received: by mail-ea0-f182.google.com with SMTP id a15so366752eae.27 for ; Wed, 04 Dec 2013 05:56:57 -0800 (PST) Date: Wed, 4 Dec 2013 14:56:54 +0100 From: Stefan Hajnoczi Message-ID: <20131204135654.GC27381@stefanha-thinkpad.redhat.com> References: <1385754746-21172-1-git-send-email-a.motakis@virtualopensystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1385754746-21172-1-git-send-email-a.motakis@virtualopensystems.com> Subject: Re: [Qemu-devel] [RFC 0/5] Vhost and vhost-net support for userspace based backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Antonios Motakis Cc: lukego@gmail.com, tech@virtualopensystems.com, qemu-devel@nongnu.org, n.nikolaev@virtualopensystems.com, "Michael S. Tsirkin" On Fri, Nov 29, 2013 at 08:52:21PM +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. One thing that came to mind when reading the patches is that you are implementing the vhost interface pretty much exactly as-is. Did you look at FUSE's character devices in userspace (CUSE)? IIRC even ioctl is supported so you might be able to skip the userspace backend entirely if you mimic vhost_net.ko's ioctl interface. Then all that's needed is some configuration/startup code to use shared memory and pass the eventfds. Stefan