On Thu, Oct 01, 2020 at 09:28:37AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > Architecturally, I think we can have 3 processes:
> > > 
> > > VMM -- guest device emulation -- host backend
> > > 
> > > to me this looks like increasing our defence in depth strength,
> > > as opposed to just shifting things around ...
> > 
> > Cool idea.
> 
> Isn't that exactly what we can do once the multi-process qemu patches
> did land, at least for block devices?  With "VMM" being main qemu,
> "guest device emulation" being offloaded to one (or more) remote qemu
> process(es), and qemu-storage-daemon being the host backend?

Status of mpqemu: the current mpqemu patch series has limited
functionality (so that we can merge it sooner rather than later). Don't
expect to use it with arbitrary PCI devices yet, only the LSI SCSI
controller.

In mpqemu (and vfio-user) QEMU handles all MMIO/PIO accesses by
forwarding them to the device emulation process. Therefore QEMU is still
involved to an extent. This can be fixed with ioeventfd for doorbells,
the proposed ioregionfd mechanism for MMIO/PIO, and vfio-user mmap
regions for RAM-backed device memory.

However, QEMU itself still emulates the PCI controller. This means
PCI configuration space and other device operations still go to QEMU. In
order to fully move emulation out of QEMU we'd need to do something more
drastic and I think this is what we're discussion in this sub-thread.

Stefan