On 21 January 2017 at 08:45, Alessandro Di Federico <ale+q...@clearmind.me> wrote: > This series of patches introduce a set of changes, mainly to the QEMU > build system, to open the way to implementing "libtcg", i.e., using > QEMU's tiny code generator frontends as a library. > > For the initial proposal, please see the related discussion: > > http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04847.html > > The idea is to build a PIC version of QEMU embedding only what's > required to use the TCG frontend (typically > target/$arch/translate.c). To achieve this, some functions have been > moved out of translate.c to reduce the coupling with the other object > files. > > All the configurations available on Linux and FreeBSD still build fine > (without warnings). > > The last commit also introduces the libtcg/ directory and a series of > *-libtcg targets (similar to the *-{bsd,linux}-user) with the bare > minimum skeleton for the actual implementation and some dummy references > to some functions that in my previous implementation of libtcg were > required, to make sure that all the required object files are linked in.
So I guess my question here is: how are we defining the boundary between libtcg and everything else? How do we disentangle or abstract away cleanly the parts of a guest CPU frontend that are annoyingly tightly coupled to the rest of the system model? Some examples: * CPU instructions for reading timers (either cycle counts, or real-time timers) * CPU instructions that need to update interrupt controller state (the ARM M profile CPUs have a bunch of these, as do GICv3 ARM CPUs) * CPUs where some CPU state is accessed via memory mapped registers (again, M profile CPUs have a lot of that) I think this is overall a good idea but I think I'll find it easier to review if I have a more solid idea of the design principles and where we're trying to draw dividing lines in the tricky cases. thanks -- PMM
