sharing intention for developing per-target, dynamically loadable accelerator modules

[Claudio Fontana]

Hello all,

my intention would be to develop per-target, dynamically loadable accelerator 
modules.

This would allow to distribute a single QEMU base binary, and then provide 
accelerators as optional additional binary packages to install,
with the first separate optional package being TCG.

CONFIG_TCG would become 'm' as a result, but then also CONFIG_KVM, CONFIG_HAX, 
CONFIG_WHPX, CONFIG_HVF.

Here are some elements that seem to be needed:

1 - The module CONFIG_MODULE part of the build system would need some extension 
to add per-target modules. I have some tentative results that shows that this 
is possible (but a bit clunky atm).
    There is some existing instability in the existing Makefile infrastructure 
of modules that shows up when trying to extend it.

2 - new "accelerator drivers" seems to be needed, either in addition or as 
additional functionality inside the current AccelState.

3 - for target/i386 in particular, there is some refactoring work needed to 
split even more different unrelated bits and pieces.
    dependencies of hw/i386 machine stuff with accelerator-specific stuff are 
also painful.

4 - CPU Arch Classes could be extended with per-accelerator methods. Initial 
fooling around shows it should probably work.
    One alternative would be trying to play with the dynamic linker (weak 
symbols, creative use of dlsym etc), but I have not sorted out the details of 
this option.

5 - cputlb, in particular tlb_flush and friends is a separate problem since it 
is not part of the cpuclass. Should it be?

6 - a painpoint is represented by the fact that in USER mode, the accel class 
is not applied, which causes a lot of uncleanliness all around
    (tcg_allowed outside of the AccelClass).

7 - I have not really thought about the KConfig aspects because I am not 
super-familiar

8 - cpus.c needs some good splitting

... more things to find out and think about ...

Overall, I think that the activity has the potential to provide benefits 
overall beyond the actual goal, in the form of cleanups, leaner configurations,
minor fixes, maybe improving the CONFIG_MODULE instabilities if any etc.

As an example, the first activity I would plan to submit as RFC is point 8 
above,
there is the split between cpus.c and cpus-tcg.c that results in lots of 
TCG-specific code being removed from non-tcg builds (using CONFIG_TCG).

One thing that should be kept in check is any performance impact of the 
changes, in particular for point 4, hot paths should probably avoid going 
through too many pointer indirections.

Does anybody share similar goals? Any major obstacle or blocker that would put 
the feasibility into question?
Any suggestion on any of this? In particular point 4 and 5 come to mind, as 
well as some better understanding of the reasons behind 6, or even suggestions 
on how to best to 2.

Anyway, I will continue to work on the first RFC for some smaller initial steps 
and hopefully have something to submit soon.

Ciao ciao,

Claudio

-- 
Claudio Fontana
Engineering Manager Virtualization, SUSE Labs Core

SUSE Software Solutions Italy Srl