Re: [Qemu-devel] [RFC PATCH 00/21] Trace updates and plugin RFC

[Alex Bennée]

Pavel Dovgalyuk <address@hidden> writes:

>> From: Alex Bennée [mailto:address@hidden
>> Pavel Dovgalyuk <address@hidden> writes:
>>
>> >> From: Alex Bennée [mailto:address@hidden
>> >> Pavel Dovgalyuk <address@hidden> writes:
>> >>
>> >> >> From: Alex Bennée [mailto:address@hidden
>> >> >> Any serious analysis tool should allow for us to track all memory
>> >> >> accesses so I think the guest_mem_before trace point should probably
>> >> >> be split into guest_mem_before_store and guest_mem_after_load. We
>> >> >> could go the whole hog and add potential trace points for start/end of
>> >> >> all memory operations.
>> >> >
>> >> > I wanted to ask about memory tracing and found this one.
>> >> > Is it possible to use tracepoints for capturing all memory accesses?
>> >> > In our implementation we insert helpers before and after tcg
>> >> > read/write operations.
>> >>
>> >> The current tracepoint isn't enough but yes I think we could. The first
>> >> thing I need to do is de-macrofy the atomic helpers a little just to
>> >> make it a bit simpler to add the before/after tracepoints.
>> >
>> > But memory accesses can use 'fast path' without the helpers.
>> > Thus you still need inserting the new helper for that case.
>>
>> trace_guest_mem_before_tcg in tcg-op.c already does this but currently
>> only before operations. That's why I want to split it and pass the
>> load/store value register values into the helpers.
>
> One more question about your trace points.
> In case of using trace point on every instruction execution, we may need
> accessing vCPU registers (including the flags). Are they valid in such
> cases?

They are probably valid but the tricky bit will be doing it in a way
that doesn't expose the internals of the TCG. Maybe we could exploit the
GDB interface for this or come up with a named referencex API.

> I'm asking, because at least i386 translation optimizes writebacks.

How so? I have to admit the i386 translation code is the most opaque to
me but I wouldn't have thought changing the semantics of the guests
load/store operations would be a sensible idea.

Of course now you mention it my thoughts about memory tracing have been
influenced by nice clean RISCy load/store architectures where it's rare
to have calculation ops working directly with memory.

>
> Pavel Dovgalyuk


--
Alex Bennée