Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu

[Stefan Hajnoczi]

On Wed, Apr 22, 2020 at 09:13:35PM -0700, address@hidden 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

signature.asc
Description: PGP signature