Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 29, 2013 at 11:31:50AM +0100, Stefano Stabellini wrote:
> On Tue, 28 May 2013, Anthony Liguori wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > 
> > > On Tue, May 28, 2013 at 12:00:38PM -0500, Anthony Liguori wrote:
> > >> Julian Stecklina <jsteckli@os.inf.tu-dresden.de> 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