On 4/15/24 12:37, Peter Maydell wrote:
On Mon, 15 Apr 2024 at 17:09, Don Porter <por...@cs.unc.edu> wrote:
This patch set adds an 'info pg' command to the monitor, which prints
a nicer view of the page tables. A project in my graduate OS course
involves implementing x86 page table support, and my students have
found this helpful for debugging.
So, my issue with this is that it's x86 specific, and it adds
yet another monitor command that is doing "show some kind of debug
info related to the guest page tables", along with "info mem"
and "info tlb". Plus it is yet another lump of code that's
walking the guest page tables and interpreting them.
What I'd really like to see is some infrastructure that is
at least somewhat guest-architecture-agnostic, so we can
minimise what a guest architecture needs to implement (and
then make providing that mandatory).
The other thing I'd like to see is perhaps some investigation of
whether there's any way to implement something useful by
using/extending the existing get_phys_page_attrs_debug() and
similar functions, so that you don't have to write one lot
of page-table-walking code for QEMU to use when it's executing
guest code and a separate lot (that's bound to get out of
sync or not support new functionality/changes) that's only
handling these monitor debug commands. There's a lot of
complexity in figuring out things like permissions in a
modern architecture...
thanks
-- PMM
Thank you for the feedback!
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.
Thoughts?
Don
