Peter Maydell writes: > On 23 February 2016 at 18:22, Lluís Vilanova <vilan...@ac.upc.edu> wrote: >> Signed-off-by: Lluís Vilanova <vilan...@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).
