[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