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

[Stafford Horne]

On Tue, Apr 18, 2017 at 08:00:06AM -0700, Richard Henderson wrote:
> 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
> > > > pages.
> > > > 
> > > > 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?

We don't,  the linux kernel is implemented with basic 2-level lookup's with
single fault.  I was just thinking its not ideal for the emulator to assume
the paging model since it could change from kernel to kernel.

But I guess it will not change anytime soon.

-Stafford