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" <m...@redhat.com> writes: > > > > > > > On Tue, May 28, 2013 at 12:00:38PM -0500, Anthony Liguori wrote: > > > >> Julian Stecklina <jstec...@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.
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?