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