Re: [Qemu-devel] [RFC PATCH v2 0/6] translate: [tcg] Generic translation framework

[Lluís Vilanova]

Alex Bennée writes:

> Lluís Vilanova <address@hidden> writes:

>> Lluís Vilanova writes:
>> 
>>> This series proposes a generic (target-agnostic) instruction translation
>>> framework.
>> 
>>> It basically provides a generic main loop for instruction disassembly, which
>>> calls target-specific functions when necessary. This generalization makes
>>> inserting new code in the main loop easier, and helps in keeping all 
>>> targets in
>>> synch as to the contents of it.
>> 
>>> I've only ported i386 as an example to get some feedback, but I'm planning 
>>> on
>>> porting ARM next to see how well it fits into the current organization.
>> 
>>> Signed-off-by: Lluís Vilanova <address@hidden>
>>> ---
>> 
>>> Changes in v2
>>> =============
>> 
>>> * Port ARM and AARCH64 targets.
>>> * Fold single-stepping checks into "max_insns" [Richard Henderson].
>>> * Move instruction start marks to target code [Richard Henderson].
>>> * Add target hook for TB start.
>>> * Check for TCG temporary leaks.
>>> * Move instruction disassembly into a target hook.
>>> * Make breakpoint_hit() return an enum to accomodate target's needs (ARM).
>> [...]
>> 
>> I'm not sure if I CC'd the appropriate people, but I'd like to know if this
>> seems like the proper approach to generalizing the main disassembly
>> loop.
>> 
>> Every time someone updates a target it becomes a little cumbersome to keep 
>> this
>> type of patches in synch (for now, only in i386 and arm).

> I'm sorry this has been in my review queue so long that it no longer
> applies cleanly. However feel free to add me on the next iteration.

Will do.


> My only general comment is I think there is a bit too much churn in the
> per-arch changes from re-names that aren't really needed. Aside from
> that it would be useful to have an example of something that can be done
> more easily in the generic run-loop as part of the series. Otherwise I
> find the churn hard to justify.

For one, it's easier to keep all main loops in synch. I've found in previous
versions that some main loops perform some of the operations in a different
order (like the order between gen_io_start() and breakpoint checks; might be
synced now, I haven't checked again).

The most prominent example I have is a later series adding support to trace what
code the guest executes on all targets (raising an event before and another
after each instruction/bbl).


Cheers,
  Lluis