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. -- MST
