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

[Stefano Stabellini]

On Tue, 28 May 2013, Anthony Liguori wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
> 
> > On Tue, May 28, 2013 at 12:00:38PM -0500, Anthony Liguori wrote:
> >> Julian Stecklina <address@hidden> 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.