On 17 March 2016 at 19:22, Lluís Vilanova <vilan...@ac.upc.edu> 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. > 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. 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). thanks -- PMM
