Re: [Qemu-devel] [RFC] Tracing guest register usage
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~
Re: [Qemu-devel] [RFC] Tracing guest register usage
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
Re: [Qemu-devel] [RFC] Tracing guest register usage
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~
Re: [Qemu-devel] [RFC] Tracing guest register usage
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
Re: [Qemu-devel] [RFC] Tracing guest register usage
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~
[Qemu-devel] [RFC] Tracing guest register usage
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
