[Crash-utility] [PATCH v3 0/6] Second phase of future support for x86_64 5-level page tables

[Dave Anderson]

----- Original Message -----
> Hi Dave,
> 
> At 01/31/2018 03:49 AM, Dave Anderson wrote:
> > 
> > Hello Dou,
> > 
> > I have reviewed this second phase patchset, and have successfully tested it
> > on
> > existing kernels.  I must say that it is *very* well done -- I truly
> > appreciate
> > the effort that you have undertaken.
> > 
> > The only thing I added was a reference to the "--machdep vm=5level"
> > command line option in the crash.8 man page and for "crash --help".
> > 
> > I've queued it for crash-7.2.1:
> >    
> >    https://github.com/crash-utility/crash/commit/94d01ce01d7bdd7e3bbc5dccb25caac438c071b6
> > 
> 
> Thank you so much for reviewing and merging this patchset.
> 
> > I look forward to phase 3!
> > 
> 
> Ok, I will try my best to do phase 3:
> 
> As you said in the changelog, the third phase contains two tasks:
> 
>    1) automatically detect whether the kernel proper for 5 level page
>       tables.
>    2) detect whether an individual user task, is utilizing 5-level page
>       tables
> 
> For task 1, I saw Kirill had sent the v8 patchset. IMO, it's better
> to do this task after kirill's patches are merged. is it right?

Sure, that's fine with me.  At that point there should just be a kernel
variable that, if it exists, and is set appropriately, would be the
best clue.

> 
> For task 2, I am sorry I have no idea about it now, I will learn it
> first, any suggestions do you have?

No, I don't understand the specifics.  The user-space reference in the
Documentation/x86/x86_64/5level-paging.txt file seems to imply that
5-level is set up on the fly if an mmap MAP_FIXED request goes beyond
the 47-bit limit (?).  Maybe it would be possible to look at the contents
of the page directory or p4d (or whichever), and check whether it "folds"
back into itself or points to the extra page of PTEs?

Thanks,
  Dave
  

> 
> Thanks,
> 	dou
> 
> > Thanks,
> >    Dave
> > 
> > ----- Original Message -----
> >> Changelog:
> >>    V1-->V2:
> >>      -Fix the backwards compatibility issues suggested by Dave
> >>      -Test with "mod","kmem -f","vm -p" command again.
> >>    V2-->V3:
> >>      -keep the pml4, upml, last_upml_read and last_pml4_read members in
> >>      struct
> >>       machine_specific like before for extension modules suggested by Dave
> >>      -move ptrs_per_pgd to the end of the machine_specific data structure
> >>      -rewirte the changelog
> >>      -rebase the patchset
> >>      -retest it
> >>
> >> I found Dave had alread done the first phase of future support for x86_64
> >> 5-level page tables(commit 307e7f35f510). when I asked him about the
> >> state of this work, he gave me a more detailed answer and suggestion.
> >> I follow his advice, and do the following job.
> >>
> >> 1. Refine the original logical:
> >>    1) Create some new common function for getting the offset of page table
> >>    2) Repace the PML4 and UPML with the common PGD:
> >>       machdep->machspec->pml4/upml ==> machdep->pdg
> >>    3) Using the PUD in x86_64
> >>
> >> 2. Add 5-level page tables support for x86_64_k/uvtop()
> >>
> >> This patchset is the second phase of the work, As Dave said, we need to be
> >> a manner of determining very early on whether the kernel page tables are
> >> using 5-level and  whether each user-space task is using 4- or 5-level
> >> page
> >> tables. These will be done after this phase.
> >>
> >> About test work:
> >>
> >> I have tested this patchset with 4-level and 5-level paging table.
> >>
> >> sadump are not be tested.
> >>
> >> Dou Liyang (6):
> >>    defs.h: Fix the PHYSICAL_PAGE_MASK macro
> >>    x86_64: Extract public page table mapping code
> >>    x86_64: Unify the page table parsing for 4-level mode
> >>    x86_64.c: Add the VMEMMAP support for 5 level page table
> >>    x86_64: Add 5-level paging support for x86_64_k/uvtop()
> >>    x86_64: Fix the misusage of PGDIR_SHIFT
> >>
> >>   defs.h   |  56 ++---
> >>   sadump.c |   7 +-
> >>   x86_64.c | 750
> >>   +++++++++++++++++++++++++++++++++------------------------------
> >>   3 files changed, 418 insertions(+), 395 deletions(-)
> >>
> >> --
> >> 2.14.3
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> 
> 
>