Re: [Qemu-devel] [RFC PATCH 0/3] Preparing the build system for libtcg

[Peter Maydell]

On 21 January 2017 at 08:45, Alessandro Di Federico
<address@hidden> 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