Re: Add 'info pg' command to monitor

["Dr. David Alan Gilbert" <dave@treblig.org>]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On Tue, 16 Apr 2024 at 19:11, Don Porter <porter@cs.unc.edu> wrote:
> >
> > On 4/16/24 13:03, Peter Maydell wrote:
> > > On Tue, 16 Apr 2024 at 17:53, Don Porter <porter@cs.unc.edu> wrote:
> > >> There is still a lot I am learning about the code base, but it seems
> > >> that qemu_get_guest_memory_mapping() does most of what one would need.
> > >> It currently only returns the "leaves" of the page table tree in a list.
> > >>
> > >> What if I extend this function with an optional argument to either
> > >> 1) return the interior nodes of the page table in additional lists (and
> > >> then parse+print in the monitor code), or
> > >> 2) inline the monitor printing in the arch-specific hook, and pass a
> > >> flag to get_guest_memory_mapping() that turns on/off the statements that
> > >> pretty print the page tables?
> > >>
> > >> It looks like most CPUs implement this function as part of checkpointing.
> > > As far as I can see only x86 implements the get_memory_mapping
> > > function, so once again somebody has added some bit of
> > > functionality that does a walk of the page tables that is
> > > x86 only and that shares no code with any of the other
> > > page table walking code :-(
> >
> > My mistake - get_memory_mappings() is only implemented in x86.
> >
> > In doing some searching of the code, many architectures implement
> > mmu_translate() and
> > get_physical_address() functions, but they are not standardized. I also
> > see your larger point
> > about replicating page walking code in x86.
> >
> > I imagine you have something in mind that abstracts things like the
> > height of the radix tree,
> > entries per node, checking permissions, printing the contents, etc.
> >
> > Perhaps I should start by trying to merge the x86 page walking code into
> > one set of common
> > helper functions, get more feedback (perhaps on a new patch thread?),
> > and then consider
> > how to abstract across architectures after getting feedback on this?
> 
> I think the cross-architecture abstraction is probably the
> trickiest part. I would actually be happy for us to drop
> 'info tlb' and 'info mem' entirely if we have a cross-arch
> command that gives basically the same information -- we don't
> IMHO need more than one command for this, and we only have
> multiple commands for basically legacy reasons. And for the
> human monitor (HMP) we don't need to keep things around
> for backwards compatibility.

I'm not sure what happens for the (MIPS/SPARC ?) where it's not
a traditional table hierarchy.

The other thing you might want (and I'm not sure how it interacts
with any of this) is to specify the root of the MMU tree (i.e. CR3
value for those in Intel thinking) to dump different processes etc.

Dave

> thanks
> -- PMM
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/