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