qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] trace: [all] Add "guest_vmem" event


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 2/5] trace: [all] Add "guest_vmem" event
Date: Sat, 19 Mar 2016 13:59:56 +0000

On 18 March 2016 at 18:50, Lluís Vilanova <address@hidden> 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

[Prev in Thread] Current Thread [Next in Thread]