From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhfUf-0006Dm-43 for qemu-devel@nongnu.org; Wed, 29 May 2013 08:28:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhfR3-00020c-Pv for qemu-devel@nongnu.org; Wed, 29 May 2013 08:25:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhfR3-00020P-Hh for qemu-devel@nongnu.org; Wed, 29 May 2013 08:24:57 -0400 Date: Wed, 29 May 2013 15:25:11 +0300 From: "Michael S. Tsirkin" Message-ID: <20130529122511.GT4472@redhat.com> 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 Content-Disposition: inline In-Reply-To: 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: Stefano Stabellini Cc: julien.grall@citrix.com, "snabb-devel@googlegroups.com" , qemu-devel@nongnu.org, Anthony Liguori , Julian Stecklina On Wed, May 29, 2013 at 11:31:50AM +0100, Stefano Stabellini wrote: > 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. I see. I think what we are discussing here is more along the lines of decoding the request in QEMU and forwarding to another process for slow-path setup. Do the bounce directly in kvm only for fast-path operations. -- MST