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 <sho...@gmail.com> > > > > > > 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
