Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code)

[Lluís Vilanova]

KONRAD Frederic writes:

> Hi,
> Le 09/03/2016 16:52, Richard Henderson a écrit :
>> On 03/09/2016 09:38 AM, Lluís Vilanova wrote:
>>> Hi,
>>> 
>>> NOTE: I won't be throwing patches anytime soon, I just want to know if
>>> there's
>>> interest in this for the future.
>>> 
>>> While adding events for tracing guest instructions, I've found that the
>>> per-target "gen_intermediate_code()" function is very similar but not 
>>> exactly
>>> the same for each of the targets. This makes architecture-agnostic features
>>> harder to maintain across targets, specially when it comes to their relative
>>> order.
>>> 
>>> So, would it be worth it if I generalized part of that code into an
>>> architecture-agnostic function that calls into target-specific hooks 
>>> wherever
>>> it
>>> needs extending? There are many ways to do it that we can discuss later.
>> 
>> It's worth talking about, since I do believe it would make long-term
>> maintenance across the targets easier.
>> 
>> These "target-specific hooks" probably ought not be "hooks" in the
>> traditional sense of attaching them to CPUState.  I'd be more comfortable 
>> with
>> a refactoring that used include files -- maybe .h or maybe .inc.c.  If we do
>> the normal sort of hook, then we've got to either expose DisasContext in
>> places we shouldn't, or dynamically allocate it.  Neither seems particularly
>> appealing.
>> 
>> 
>> r~
>> 

> On the other side I think attaching them to CPUState would make heterogenous
> system emulation easier?

Yes, that's something to take into account too. But for this I think that
"gen_intermediate_code()" would suffice.

Still, abstracting it into the level of KVM vs. TCG would be even more
interesting, since we could switch between backends, or even have different CPUs
using different backends (e.g., trace a TCG vCPU while another runs at full
speed using KVM). For example, there could be a virtual "exec()" method,
although reality is not that straightforward since each KVM vCPU runs on a
different thread, while in TCG this is not necessarily so (even with MTTCG).


Cheers,
  Lluis