On Fri, Oct 05, 2018 at 01:50:10PM +0200, Sergio Lopez wrote: > Hi, > > I have an idea in mind that I'd like to share to ask you if you think > it's worth giving it a try. > > Right now, vmd already features an excellent privsep model to ensure > the process servicing the VM requests to the outside world is running > with the lowest possible privileges. > > I was wondering if we could take a step further, servicing each virtio > device from a different process. This design would simplify the > implementation and maintenance of those devices, improve the privsep > model and increase the resilience of VMs (the crash of a process > servicing a device won't bring down the whole VM, and a mechanism to > recover from this scenario could be explored). > > Doing this in an efficient way requires: > > - The ability to receive virtqueue notifications directly on the > process. I've already sent an RFC patch for this (see "Lightweight > mechanism to kick virtio VQs"), as it'd be useful for the non-separated > model too. > > - An in-kernel IRQ chip. This one is the most controversial, as it > means emulating a device from a privileged domain, but I'm pretty sure > a lapic implementation with enough functionality to serve *BSD/Linux > Guests can be small and simple enough to be easily auditable. > > - A way to map the VM memory into a third process context. Can > uvm_share for this? Here's also the opportunity to explore options to > avoid mapping the whole VM memory, though that'll possibly require > functionality non covered by the virtio specs. > > Do you think it's worth exploring this model? What are feelings > regarding the in-kernel IRQ chip? > > Sergio (slp). >
Lots of things to read through in this and the attached diff. I'll try to catch up and reply as soon as I can. -ml
