[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Add 'info pg' command to monitor
|
From: |
Dr. David Alan Gilbert |
|
Subject: |
Re: Add 'info pg' command to monitor |
|
Date: |
Wed, 17 Apr 2024 21:03:33 +0000 |
|
User-agent: |
Mutt/2.2.12 (2023-09-09) |
* 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?
>
> In looking at x86 code, I see the following places where there is page table
> walking code to
> potentially merge:
>
> * target/i386/monitor.c - existing info commands
>
> * target/i386/helper.c - get_phys_page_attrs_debug
>
> * target/i386/arch_memory_mapping.c - implements get_memory_mapping
>
> * tcg/sysemu/excp_helper.c: implements mmu_translate() and
> get_physical_address()
One thing to keep in mind (although I don't know the x86 code) is that
you want the monitor command not to change any state, nor to fail if
there's a particularly screwy page table; so no flagging exceptions
or flagging accessed bits or changing the state of the tcg.
Dave
> Thanks,
>
> Don
>
--
-----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 |_______/
- Add 'info pg' command to monitor, Don Porter, 2024/04/15
- [PATCH 1/2] monitor: Implement a generic x86 page table iterator, Don Porter, 2024/04/15
- [PATCH 2/2] monitor: Add an "info pg" command that prints the current page tables, Don Porter, 2024/04/15
- Re: Add 'info pg' command to monitor, Peter Maydell, 2024/04/15
- Re: Add 'info pg' command to monitor, Peter Maydell, 2024/04/19
- Re: Add 'info pg' command to monitor, Dr. David Alan Gilbert, 2024/04/19