From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhP3d-00014q-77 for qemu-devel@nongnu.org; Tue, 28 May 2013 14:55:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhP3Y-0002wM-Az for qemu-devel@nongnu.org; Tue, 28 May 2013 14:55:41 -0400 Received: from mail-ob0-x22f.google.com ([2607:f8b0:4003:c01::22f]:35811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhP3Y-0002wI-6X for qemu-devel@nongnu.org; Tue, 28 May 2013 14:55:36 -0400 Received: by mail-ob0-f175.google.com with SMTP id xn12so6152153obc.20 for ; Tue, 28 May 2013 11:55:35 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20130528171742.GB30296@redhat.com> References: <20130527093409.GH21969@stefanha-thinkpad.redhat.com> <51A496C4.1020602@os.inf.tu-dresden.de> <87r4grca4p.fsf@codemonkey.ws> <20130528171742.GB30296@redhat.com> Date: Tue, 28 May 2013 13:55:31 -0500 Message-ID: <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: "Michael S. Tsirkin" Cc: "snabb-devel@googlegroups.com" , qemu-devel@nongnu.org, Stefano Stabellini , Julian Stecklina "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. Regards, Anthony Liguori > We can kill this process if there's a bug > with the result that NIC gets stalled but everything else > keeps going. > Possibly restart on next guest reset. > There could be other advantages. > > -- > MST