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

[Stefano Stabellini]

On Wed, 29 May 2013, Michael S. Tsirkin wrote:
> On Wed, May 29, 2013 at 11:31:50AM +0100, Stefano Stabellini wrote:
> > 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.
> 
> 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.

So you would keep the PCI decoder in QEMU.
However you would still need an interface to register more than one QEMU
process with KVM for the fast-path operations, right?
How do you think that this interface would look like?