* [Qemu-devel] [RFC] Tracing guest register usage
@ 2016-09-28 13:21 Lluís Vilanova
2016-09-28 17:18 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Lluís Vilanova @ 2016-09-28 13:21 UTC (permalink / raw)
To: qemu-devel; +Cc: Paolo Bonzini, Peter Crosthwaite, Richard Henderson
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).
While enough, I'm wondering if extending "tcg_global_mem_new_*" to set that
mapping is the proper way to go. For example, gdbstub also has some form of
guest (vCPU) register descriptors, but only for some of the targets.
So the question is wether it's worth generalizing this to some register
descriptors in CPUClass, that can be used by all QEMU's subsystems.
Cheers,
Lluis
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] [RFC] Tracing guest register usage
2016-09-28 13:21 [Qemu-devel] [RFC] Tracing guest register usage Lluís Vilanova
@ 2016-09-28 17:18 ` Richard Henderson
2016-09-30 15:13 ` Lluís Vilanova
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2016-09-28 17:18 UTC (permalink / raw)
To: qemu-devel, Paolo Bonzini, Peter Crosthwaite
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?
As for the CC register split, there will be (1) groups of assignments that
correspond to a single change of the register and (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.
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).
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] Tracing guest register usage
2016-09-28 17:18 ` Richard Henderson
@ 2016-09-30 15:13 ` Lluís Vilanova
2016-09-30 18:56 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Lluís Vilanova @ 2016-09-30 15:13 UTC (permalink / raw)
To: Richard Henderson
Cc: qemu-devel, Paolo Bonzini, Peter Crosthwaite, Stefan Hajnoczi
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] Tracing guest register usage
2016-09-30 15:13 ` Lluís Vilanova
@ 2016-09-30 18:56 ` Richard Henderson
2016-10-05 10:06 ` Lluís Vilanova
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2016-09-30 18:56 UTC (permalink / raw)
To: qemu-devel, Paolo Bonzini, Peter Crosthwaite, Stefan Hajnoczi
On 09/30/2016 08:13 AM, Lluís Vilanova wrote:
>> (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.
It sets cc_op, which affects how eflags is computed.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] Tracing guest register usage
2016-09-30 18:56 ` Richard Henderson
@ 2016-10-05 10:06 ` Lluís Vilanova
2016-10-05 16:16 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Lluís Vilanova @ 2016-10-05 10:06 UTC (permalink / raw)
To: Richard Henderson
Cc: qemu-devel, Paolo Bonzini, Peter Crosthwaite, Stefan Hajnoczi
Richard Henderson writes:
> On 09/30/2016 08:13 AM, Lluís Vilanova wrote:
>>> (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.
> It sets cc_op, which affects how eflags is computed.
I see tcg_gen_insn_start() gets dc->cc_op as a second argument, but I really
don't see where it gets modified (I'm looking at tcg_gen_code() on the
INDEX_op_insn_start case).
If you have the time, I'd like to understand that; I'm just curious.
But regardless of this specific case, we still have all the instructions
implemented with TCG helpers, which won't have any reguster usage information. I
was pretty convinced that was enough for some basic analysis using the traces,
but I might just as well keep proper register usage on my instrumentation tree.
Thanks,
Lluis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] Tracing guest register usage
2016-10-05 10:06 ` Lluís Vilanova
@ 2016-10-05 16:16 ` Richard Henderson
0 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2016-10-05 16:16 UTC (permalink / raw)
To: qemu-devel, Paolo Bonzini, Peter Crosthwaite, Stefan Hajnoczi
On 10/05/2016 03:06 AM, Lluís Vilanova wrote:
> Richard Henderson writes:
>
>> On 09/30/2016 08:13 AM, Lluís Vilanova wrote:
>>>> (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.
>
>> It sets cc_op, which affects how eflags is computed.
>
> I see tcg_gen_insn_start() gets dc->cc_op as a second argument, but I really
> don't see where it gets modified (I'm looking at tcg_gen_code() on the
> INDEX_op_insn_start case).
The ultimate change is in restore_state_to_opc, via cpu_restore_state.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-05 16:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-28 13:21 [Qemu-devel] [RFC] Tracing guest register usage Lluís Vilanova
2016-09-28 17:18 ` Richard Henderson
2016-09-30 15:13 ` Lluís Vilanova
2016-09-30 18:56 ` Richard Henderson
2016-10-05 10:06 ` Lluís Vilanova
2016-10-05 16:16 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).