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

Reply via email to