qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Tracing guest register usage


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [RFC] Tracing guest register usage
Date: Fri, 30 Sep 2016 17:13:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Richard Henderson writes:

> On 09/28/2016 06:21 AM, Lluís Vilanova wrote:
>> Hi! I've kept working on extending the guest instruction tracing features, 
>> and
>> added support to trace which registers are read/written by guest instructions
>> (when executing with TCG).
>> 
>> I've basically extended "tcg_global_mem_new_*" to associate global TCG 
>> registers
>> with a guest (vCPU) register number (*), and track all TCG opcodes that 
>> access
>> the values of these global TCG registers.
>> 
>> (*) This "mapping" is necessary because targets like i386 have multiple 
>> global
>> TCG registers (cc_dst, cc_src, ...) that correspond to a single guest
>> register (eflags).

> Is tracing all changes to a register something that's actually going to be
> useful?  If I were to log all changes to EAX, what would that tell me?

That's a good question. I'm using it to reconstruct data dependencies in
instruction traces, and others have posted other ad-hoc solutions to get this
type of information before.

If QEMU considers this type of information is not useful, I will move it to my
private tree.


> As for the CC register split, there will be (1) groups of assignments that
> correspond to a single change of the register and

I have those covered. Marking a read/write to a guest register is an idempotent
operation, since I trace those on a bitmask (even if the guest register is split
into multiple global TCG registers, that's what I have the mapping for). The
instruction trace events basically have two additional arguments (bitmasks): a
read set and a write set.


> (2) an internal state change
> to DisasContext, reflected in INDEX_op_insn_start, with no changes to any TCG
> registers.  So you'll not actually be tracking eflags at all.

I don't follow what you mean. AFAIK INDEX_op_insn_start does not change the
guest eflags.


> This seems like something that should actually apply to cpu internal 
> registers,
> such as CR4, which are never TCG registers (and moreover are never manipulated
> from TCG code at all).

I'm aware that register accesses would not be traced for instructions
implemented in helpers. The information is thus "best effort", but good enough
for the majority of instructions, which are implemented in TCG.


Thanks,
  Lluis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]