Re: [Qemu-devel] [PATCH 2/5] trace: [all] Add "guest_vmem" event

[Lluís Vilanova]

Peter Maydell writes:

> On 17 March 2016 at 19:22, Lluís Vilanova <address@hidden> wrote:
>> Mmmmm, the endianness seems more of a vCPU property than one of the memory
>> access. A separate event could be added for that (e.g., at vCPU
>> initalization/hot-plug and whenever it is dynamically changed like in ARM).

> We've chosen to implement it in QEMU as a property of the memory
> access. Consider for instance instructions like x86 movbe --
> sometimes an individual instruction will be a BE access even if the
> CPU more usually does LE accesses. Equally, CPUs might have different
> accesses for data and code, or other complicated things.
> I think we're probably better off tracing as part of the memory
> access the things we've implemented as memory access properties
> or flags; at least that's consistent.

Oh, I wasn't aware of the endinness swapping, but your argument makes sense.


>> For the sign extension and memory value, what about adding multiple events?
>> What I did for instructions is have a simple event and one with extended
>> information, so that we can tweak performance of a tracing QEMU by choosing 
>> one
>> or the other.  We could do the same for memory accesses (e.g., also show the
>> memory value, sign extension and physical address).

> I think the info that's in the memop value is probably worth
> just printing always, it won't make much difference.

But is the endianness, sign extension, etc. valuable information when the data
is not part of the trace?

If it is, I can easily add that; but, there is still some additional
per-argument overhead when generating a TCG call to the exec-time tracing
routine, thus my target on adding two trace events with different levels of
detail. I haven't measured the impact, though.


> Trying to trace physaddrs is very tricky -- in the case of
> a TLB hit there is no guarantee you can still identify the
> physaddr of what you're accessing (the guest might have
> changed the page tables and not invalidated the TLB).

I was looking at how to modify the soft TLB code to generate that information
for the trace event, but it requires changes at every TCG target. But in any
case, that should always provide the same phys address used by QEMU, so the
event info is "correct" in that sense. Or did I miss something?


Cheers,
  Lluis