[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 1/7] target/openrisc: Fixes for memory debugging

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 1/7] target/openrisc: Fixes for memory debugging
Date: Tue, 18 Apr 2017 08:00:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 04/18/2017 07:18 AM, Stafford Horne wrote:
On Tue, Apr 18, 2017 at 12:47:30AM -0700, Richard Henderson wrote:
On 04/16/2017 04:23 PM, Stafford Horne wrote:
When debugging in gdb you might want to inspect instructions in mapped
pages or in exception vectors like 0x800 etc.  This was previously not
possible in qemu since the *get_phys_page_debug() routine only looked
into the data tlb.

Change to fall back to look into instruction tlb and plain physical

Signed-off-by: Stafford Horne <address@hidden>

Oh the horrors of a software managed TLB.

You might do well to architecturally define an SPR that holds the page table
base, even if for real hardware that's only used by the software refill to
load up the address.

That would give qemu the option of performing a real page table walk.  This
would fix this debug hook properly (so that you can examine pages that
aren't in the TLB at all).  It would also optionally allow QEMU to skip the
software refill, which *significantly* speeds up emulation.

Understood, I guess we would also need a way to represent which paging
model we are using (1 level, 2 level etc)?

I suppose. You really have a 1-level lookup? For huge pages only, or is this a virtual 2-level lookup with double-faulting to handle the second level?


reply via email to

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