qemu-devel
[Top][All Lists]
Advanced

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

Re: Add 'info pg' command to monitor


From: Peter Maydell
Subject: Re: Add 'info pg' command to monitor
Date: Fri, 19 Apr 2024 15:47:54 +0100

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.

thanks
-- PMM



reply via email to

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