On Tue, Apr 28, 2020 at 06:29:20PM +0100, Stefan Hajnoczi wrote: > On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimts...@oracle.com wrote: > > We will post separate patchsets for the following improvements for > > the experimental Qemu multi-process: > > - Live migration; > > - Asynchronous communication channel; > > - Libvirt support; > > > > We welcome all your ideas, concerns, and questions for this patchset. > > This patch series does two things: > 1. It introduces the remote device infrastructure. > 2. It creates the remote device program and the associated build changes > (makefiles, stubs, etc). > > There are many patches and it's likely that a bunch more revisions will > be necessary before this can be merged. > > I want to share an idea to reduce the scope and get patches merged more > quickly. It looks like the series can be reduced to 21 patches using > this approach. > > I suggest dropping the remote device program from this patch series (and > maybe never bringing it back). Instead, use the softmmu target for the > remote device. > > Why? Because the remote device program is just a QEMU that uses the > remote machine type and has no vCPUs: > > $ qemu-system-x86_64 -chardev id=char0,... \ > -M remote,chardev=char0 \ > -device lsi53c810 \ > -drive if=none,id=drive0,file=vm.img,format=raw \ > -device scsi-hd,drive=drive0 > > This will use the remote machine type, interrupt controller, and PCI bus > that you have created. > > The remote machine type should default to no vCPUs and no memory > creation (the memory comes via the mpqemu link communications channel). > > At this point qemu-system-x86_64 contains a lot of code that you don't > want in the final remote device program. Let's ignore that for a > second. > > Now you can submit a 21-patch series containing just the remote device > infrastructure. This will be easier to merge. > > Returning to code size, the next step is to reduce the binary. QEMU has > a Kconfig-style system for optional features and dependencies. It's a > better approach than creating a separate make target because it > eliminates the duplication and mess in the makefiles. > > For example, you can disable TCG and KVM so that your binary has no > ability to execute guest code. Currently ./configure disallows this but > I've tried it and it works. > > You can add a new default-configs/ file that disables CONFIG_ISAPC, > CONFIG_I440FX, etc. When you compile QEMU most of hw/ will not be built > anymore. At this point you have a smaller binary that is still a > softmmu target so the makefiles are shared with the regular > qemu-system-x86_64. > > There will be some code for which there is no Kconfig option yet. > Further improvements can be made by adding Kconfig options for any code > that you wish to eliminate. Instead of writing makefile changes like > you did in this patch series you would be adding Kconfig options. The > nice thing is that this work isn't specific to the remote device program > - anyone can use the new Kconfig options to reduce the size of their > QEMU. So not only is it less messy than duplicating the makefiles, > but it also benefits everyone. > > The downside to doing this is that it will take a while to eliminate all > code that you don't want via Kconfig. However, your initial patch > series can be merged sooner and I think this direction is also cleaner. > > I hope I've explained the idea properly :). We can continue reviewing > the current series if you prefer, but I think it would be quicker to > drop the remote device program. > > Stefan
Building QEMU twices just to get the remote is however not very attractive. So how about making remote a special target? Either remote-softmmu/ or if impossible x86_64-remote-softmmu/ -- MST
