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

["Lluís Vilanova" <vilanova@ac.upc.edu>]

Peter Maydell writes:

> On 23 February 2016 at 18:22, Lluís Vilanova <vilanova@ac.upc.edu> wrote:
>> Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>

>> +### Guest events, keep at bottom
>> +
>> +# @vaddr: Access' virtual address.
>> +# @size : Access' size (bytes).
>> +# @store: Whether the access is a store.
>> +#
>> +# Start virtual memory access (before any potential access violation).
>> +#
>> +# Does not include memory accesses performed by devices.
>> +#
>> +# Targets: TCG(all)
>> +disable vcpu tcg guest_vmem(TCGv vaddr, uint8_t size, uint8_t store) "size=%d store=%d", "vaddr=0x%016"PRIx64" size=%d store=%d"

> Shouldn't we also be tracing some of the other information in the memop?
> In particular, endianness of the access seems useful. You could also
> say whether we're zero- or sign-extending the access, though I guess
> you could defend not printing that since we don't print anything about
> what the target- code does with the loaded data.

> Otherwise I think this looks OK (though the various paths memory accesses
> take are a bit opaque since I've forgotten how this bit of QEMU works).

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).

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).