From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhIic-0002KA-P5 for qemu-devel@nongnu.org; Tue, 28 May 2013 08:09:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhIiT-00004x-5a for qemu-devel@nongnu.org; Tue, 28 May 2013 08:09:34 -0400 Received: from os.inf.tu-dresden.de ([2002:8d4c:3001:48::99]:37294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhIiS-00004s-U6 for qemu-devel@nongnu.org; Tue, 28 May 2013 08:09:25 -0400 Message-ID: <51A49E71.7030908@os.inf.tu-dresden.de> Date: Tue, 28 May 2013 14:09:21 +0200 From: Julian Stecklina MIME-Version: 1.0 References: <20130527093409.GH21969@stefanha-thinkpad.redhat.com> <51A496C4.1020602@os.inf.tu-dresden.de> <20130528115326.GB21107@redhat.com> In-Reply-To: <20130528115326.GB21107@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "snabb-devel@googlegroups.com" , qemu-devel@nongnu.org On 05/28/2013 01:53 PM, Michael S. Tsirkin wrote: > Implementing out of process device logic would absolutely be useful for > qemu, for security. > > Don't expect it to be zero overhead though, latency overhead > of bouncing each packet through multiple processes would > be especially painful. Currently, latency for vhost is also quite bad compared to what it could be, because for VM-to-VM packets usually 4 CPUs are involved. The CPU that VM A's vcpu thread runs on, the CPU its vhost thread in the kernel runs on, the CPU VM B's vhost thread runs on and finally the CPU VM B's vcpu thread runs on. It is possible to change the vhost implementation in the kernel to handle packet transmission to local VMs in a single thread, but it is rather hard. I have a hacky patch that implements that (that unfortunately I cannot make public :( ) and it improves latency and CPU utlization. I would suppose a userspace implementation of this is way simpler and still give most of the performance benefits. It also removes the virtio implementation in the kernel (vhost) from the trusted computing base of other stuff in the system. IMHO implementing device emulation in the kernel is plain wrong from a security perspective. Julian