Peter Maydell writes: > On 18 March 2016 at 18:50, Lluís Vilanova <vilan...@ac.upc.edu> wrote: >> Peter Maydell writes: >>> 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?
> Consider the sequence: > * guest makes access to vaddr V, currently mapped to physaddr P1 > (which is host address H) > * we put the mapping V -> H into QEMU's TLB > * guest changes its page tables so V now maps to P2, > but doesn't do a TLB flush > * guest makes another access to vaddr V > * we hit in QEMU's TLB, so we know V and H; but we don't > know P1 (because we don't record that in the TLB) and we > can't even get it by walking the page table because > at this point V maps to P2, not P1. (And for sw-TLB > guest archs like MIPS you can't even do a V-to-P lookup > in QEMU non-intrusively.) > (This is often defined to be unpredictable or similar in the guest > architecture. But a buggy guest might do it, and tracing the > wrong thing would be pretty confusing if you were trying to > track down that bug.) Oh! Yes, I seem to remember that code path now, I checked it a really long time ago. I was assuming that whenever this event is enabled at compile time, I would have to modify QEMU's TLB to store the guest physical address (then used by the tracing event). Cheers, Lluis