Re: [Qemu-devel] [RFC PATCH v2 06/35] multi-process: build system for remote device process

[Kevin Wolf]

Am 18.06.2019 um 08:24 hat Gerd Hoffmann geschrieben:
>   Hi,
> 
> > +#########################################################
> > +# remote-pci-obj-y is common code used by remote devices
> > +
> > +remote-pci-obj-$(CONFIG_MPQEMU) += hw/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += qom/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += backends/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += block/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += migration/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += remote/
> > +
> > +remote-pci-obj-$(CONFIG_MPQEMU) += cpus-common.o
> > +remote-pci-obj-$(CONFIG_MPQEMU) += dma-helpers.o
> > +remote-pci-obj-$(CONFIG_MPQEMU) += blockdev.o
> > +remote-pci-obj-$(CONFIG_MPQEMU) += qdev-monitor.o
> > +remote-pci-obj-$(CONFIG_MPQEMU) += bootdevice.o
> > +remote-pci-obj-$(CONFIG_MPQEMU) += iothread.o
> 
> > +all-remote-pci-obj-y += $(authz-obj-y)
> > +all-remote-pci-obj-y += $(block-obj-y)
> > +all-remote-pci-obj-y += $(crypto-obj-y)
> > +all-remote-pci-obj-y += $(io-obj-y)
> > +all-remote-pci-obj-y += $(chardev-obj-y)
> > +all-remote-pci-obj-y += $(remote-pci-obj-y)
> 
> > +remote-pci-obj-$(CONFIG_MPQEMU) += core/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += block/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += pci/
> > +remote-pci-obj-$(CONFIG_MPQEMU) += nvram/
> 
> Phew.  So you are building half of qemu into the remote process.
> 
> Wouldn't it be more useful to split off much smaller, well-defined
> pieces into separate processes?
> 
> Splitting off the block layer looks like a good candidate to me.  You'll
> have a qemu-remote-block[1] then which should not need much beside
> block/, and a small blockdev-proxy in qemu which talks to
> qemu-remote-block instead of accessing the disk image by itself.  It's
> also a nice improvement from the security point of view, even without
> moving the device emulation too, because the main qemu process doesn't
> need access to the image files any more.

I am already playing with an external storage daemon, which would
probably also cover these use cases. It won't be quite as small as you
suggest (e.g. it will have its own QMP interface), but it will still
separate image file handling from the process actually running the
guest.

The idea is to let it export images via the vhost-user protocol, but I
haven't actually started to implement that part yet (at the moment it's
essentially a qemu-nbd replacement that has a QMP monitor that doesn't
understand any commands).

In any case, if you start splitting off smaller pieces, don't use the
block layer because it would be duplicated work.

Kevin