From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhdfv-0001U0-Dn for qemu-devel@nongnu.org; Wed, 29 May 2013 06:32:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uhdft-0006Bk-Kj for qemu-devel@nongnu.org; Wed, 29 May 2013 06:32:11 -0400 Received: from smtp.citrix.com ([66.165.176.89]:41945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhdft-0006BH-G1 for qemu-devel@nongnu.org; Wed, 29 May 2013 06:32:09 -0400 Date: Wed, 29 May 2013 11:31:50 +0100 From: Stefano Stabellini In-Reply-To: <8761y3vsrg.fsf@codemonkey.ws> Message-ID: References: <20130527093409.GH21969@stefanha-thinkpad.redhat.com> <51A496C4.1020602@os.inf.tu-dresden.de> <87r4grca4p.fsf@codemonkey.ws> <20130528171742.GB30296@redhat.com> <8761y3vsrg.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: Anthony Liguori Cc: "snabb-devel@googlegroups.com" , Stefano Stabellini , "Michael S. Tsirkin" , qemu-devel@nongnu.org, julien.grall@citrix.com, Julian Stecklina On Tue, 28 May 2013, Anthony Liguori wrote: > "Michael S. Tsirkin" writes: > > > On Tue, May 28, 2013 at 12:00:38PM -0500, Anthony Liguori wrote: > >> Julian Stecklina writes: > >> > >> > >> I don't see any compelling reason to do something like this. It's > >> jumping through a tremendous number of hoops to avoid putting code that > >> belongs in QEMU in tree. > >> > >> Regards, > >> > >> Anthony Liguori > >> > >> > > >> > Julian > > > > OTOH an in-tree device that runs in a separate process would > > be useful e.g. for security. > > An *in-tree* device would at least be a reasonable place to have a discussion. > > I still think it's pretty hard to make work beyond just a hack. > > > For example, we could limit a virtio-net device process > > to only access tap and vhost files. > > Stefano et al from the Xen community have some interest in this. I > believe they've done some initial prototyping already. Right, what Michael said are exactly the principal reasons why Julien started working on this a while back: http://marc.info/?l=qemu-devel&m=134566472209750&w=2 http://marc.info/?l=qemu-devel&m=134566262709001&w=2 Although he had a prototype fully running, the code never went upstream, and now Julien is working on something else. The work was based on Xen and the idea that you can have multiple device models (multiple QEMU instances) each of them emulating a different set of devices for the guest VM. Each device model would register with Xen the devices that is emulating and the corresponding MMIO regions for which it wants to receive IO requests. When the guest traps into Xen on a MMIO read/write, Xen would forward the IO emulation request to the right device model instance. This is very useful for reliability, because if you have a bug in your network device emulator is not going to bring down all the QEMU instances, just the one running the network device, and could be restarted without compromising the stability of the whole system. It is good for security, because you can limit what each QEMU process can do in a much more fine grained way. And of course on Xen you can go much farther by running the QEMU instances in different domains altogether. It is good for isolation because the QEMU processes don't need to be fully privileged and are completely isolated from one another so if a malicious guest manages to break into one of them, for example because the network device has a security vulnerability, it won't be able to cause issues to the others.