> On 17 Apr 2024, at 11:30, Nadav Amit <nadav.a...@gmail.com> wrote:
> 
> 
> 
>> On 16 Apr 2024, at 21:11, Don Porter <por...@cs.unc.edu> wrote:
>> 
>> On 4/16/24 13:03, Peter Maydell wrote:
>>> On Tue, 16 Apr 2024 at 17:53, Don Porter <por...@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.
>> 
> 
> Hi Don,
> 
> Your email popped up, so I just drop my 2 cents.
> 
> If you are only interested in x86, you can just build a gdb script that would
> parse the page tables and present the data. It might be less efficient, but
> easier to maintain.

Actually, I think I was wrong. It might not be easily done with GDB, but I did
something similar with QMP.

You can have a look at some related code I once wrote for similar purpose:
https://nadav.amit.zone/downloads/pti_test.py


Reply via email to