9:51 p.m.
Currently, Crash only enable support for kernel-only 5-level page tables by
entering the command line option "--machdep vm=5level". Since Linux 4.17,
the Linux kernel can be both 4level and 5level page tables. This command line
can't work well for this.
Using the "pgtable_l5_enabled" to detect whether the kernel proper for 5 level
page tables automatically. Also move the 5-level paging setup from machdep_init(PRE_GDB)
to machdep_init(POST_RELOC).
Signed-off-by: Dave Anderson <anderson(a)redhat.com>
Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
---
Changelog v1 --> v2
1. Make it support live systems suggested by Dave
2. Using __pgtable_l5_enabled for check.
3. Do some tests in both kdump(5level and 4level) and virsh dump(5level and 4level)
---
x86_64.c | 56 +++++++++++++++++++++++++++++++++++++-------------------
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/x86_64.c b/x86_64.c
index 6d1ae2f..07b6aa9 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -294,25 +294,6 @@ x86_64_init(int when)
machdep->machspec->pgdir_shift = PGDIR_SHIFT;
machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD;
break;
-
- case VM_5LEVEL:
- machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
- machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
- machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
- machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
- machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
- machdep->machspec->modules_end = MODULES_END_5LEVEL;
- machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
- machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
- if (symbol_exists("vmemmap_populate"))
- machdep->flags |= VMEMMAP;
- machdep->machspec->physical_mask_shift = __PHYSICAL_MASK_SHIFT_5LEVEL;
- machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
- machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
- if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
- error(FATAL, "cannot malloc p4d space.");
- machdep->machspec->last_p4d_read = 0;
- machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional per-task */
}
machdep->kvbase = (ulong)PAGE_OFFSET;
machdep->identity_map_base = (ulong)PAGE_OFFSET;
@@ -346,6 +327,43 @@ x86_64_init(int when)
break;
case POST_RELOC:
+ /* Check for 5-level paging */
+ if (!(machdep->flags & VM_5LEVEL)) {
+ int l5_enabled;
+ if ((string = pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)"))) {
+ l5_enabled = 1;
+ free(string);
+ } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
+ readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
+ &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
+ FAULT_ON_ERROR);
+
+ if (l5_enabled)
+ machdep->flags |= VM_5LEVEL;
+ }
+ if (machdep->flags & VM_5LEVEL) {
+ machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
+ machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
+ machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
+ machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
+ machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
+ machdep->machspec->modules_end = MODULES_END_5LEVEL;
+ machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
+ machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
+ if (symbol_exists("vmemmap_populate"))
+ machdep->flags |= VMEMMAP;
+ machdep->machspec->physical_mask_shift = __PHYSICAL_MASK_SHIFT_5LEVEL;
+ machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
+ machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
+ if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
+ error(FATAL, "cannot malloc p4d space.");
+ machdep->machspec->last_p4d_read = 0;
+ machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional per-task */
+ machdep->kvbase = (ulong)PAGE_OFFSET;
+ machdep->identity_map_base = (ulong)PAGE_OFFSET;
+
+ }
+
/*
* Check for CONFIG_RANDOMIZE_MEMORY, and set page_offset here.
* The remainder of the virtual address range setups will get
--
2.14.3
10:30 a.m.
Hello Dou,
This patch was failing on most -- but not all -- of my test dumpfiles, because of
fatal read or seek errors during session initialization.
As it turns out, the "l5_enabled" local variable needs to be zeroed-out, because
if neither the "if" or the "else" are true, it uses whatever old stack
garbage
that l5_enabled contains:
+ /* Check for 5-level paging */
+ if (!(machdep->flags & VM_5LEVEL)) {
+ int l5_enabled;
+ if ((string = pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)"))) {
+ l5_enabled = 1;
+ free(string);
+ } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
+ readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
+ &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
+ FAULT_ON_ERROR);
+
+ if (l5_enabled)
+ machdep->flags |= VM_5LEVEL;
+ }
I'll fix that and retest.
Thanks,
Dave
----- Original Message -----
> Currently, Crash only enable support for kernel-only 5-level page tables by
> entering the command line option "--machdep vm=5level". Since Linux 4.17,
> the Linux kernel can be both 4level and 5level page tables. This command line
> can't work well for this.
>
> Using the "pgtable_l5_enabled" to detect whether the kernel proper for 5
> level
> page tables automatically. Also move the 5-level paging setup from
> machdep_init(PRE_GDB)
> to machdep_init(POST_RELOC).
>
> Signed-off-by: Dave Anderson <anderson(a)redhat.com>
> Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
> ---
> Changelog v1 --> v2
>
> 1. Make it support live systems suggested by Dave
> 2. Using __pgtable_l5_enabled for check.
> 3. Do some tests in both kdump(5level and 4level) and virsh dump(5level and
> 4level)
> ---
> x86_64.c | 56 +++++++++++++++++++++++++++++++++++++-------------------
> 1 file changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/x86_64.c b/x86_64.c
> index 6d1ae2f..07b6aa9 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -294,25 +294,6 @@ x86_64_init(int when)
> machdep->machspec->pgdir_shift = PGDIR_SHIFT;
> machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD;
> break;
> -
> - case VM_5LEVEL:
> - machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
> - machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
> - machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
> - machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
> - machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
> - machdep->machspec->modules_end = MODULES_END_5LEVEL;
> - machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
> - machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
> - if (symbol_exists("vmemmap_populate"))
> - machdep->flags |= VMEMMAP;
> - machdep->machspec->physical_mask_shift = __PHYSICAL_MASK_SHIFT_5LEVEL;
> - machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
> - machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
> - if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
> - error(FATAL, "cannot malloc p4d space.");
> - machdep->machspec->last_p4d_read = 0;
> - machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional per-task */
> }
> machdep->kvbase = (ulong)PAGE_OFFSET;
> machdep->identity_map_base = (ulong)PAGE_OFFSET;
> @@ -346,6 +327,43 @@ x86_64_init(int when)
> break;
>
> case POST_RELOC:
+ /* Check for 5-level paging */
+ if (!(machdep->flags & VM_5LEVEL)) {
+ int l5_enabled;
+ if ((string = pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)"))) {
+ l5_enabled = 1;
+ free(string);
+ } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
+ readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
+ &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
+ FAULT_ON_ERROR);
+
+ if (l5_enabled)
+ machdep->flags |= VM_5LEVEL;
+ }
> + if (machdep->flags & VM_5LEVEL) {
> + machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
> + machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
> + machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
> + machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
> + machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
> + machdep->machspec->modules_end = MODULES_END_5LEVEL;
> + machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
> + machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
> + if (symbol_exists("vmemmap_populate"))
> + machdep->flags |= VMEMMAP;
> + machdep->machspec->physical_mask_shift = __PHYSICAL_MASK_SHIFT_5LEVEL;
> + machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
> + machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
> + if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
> + error(FATAL, "cannot malloc p4d space.");
> + machdep->machspec->last_p4d_read = 0;
> + machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional per-task */
> + machdep->kvbase = (ulong)PAGE_OFFSET;
> + machdep->identity_map_base = (ulong)PAGE_OFFSET;
> +
> + }
> +
> /*
> * Check for CONFIG_RANDOMIZE_MEMORY, and set page_offset here.
> * The remainder of the virtual address range setups will get
> --
> 2.14.3
>
>
>
>
1:01 p.m.
----- Original Message -----
Hello Dou,
This patch was failing on most -- but not all -- of my test dumpfiles, because of
fatal read or seek errors during session initialization.
As it turns out, the "l5_enabled" local variable needs to be zeroed-out,
because
if neither the "if" or the "else" are true, it uses whatever old
stack garbage
that l5_enabled contains:
> + /* Check for 5-level paging */
> + if (!(machdep->flags & VM_5LEVEL)) {
> + int l5_enabled;
> + if ((string = pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)")))
{
> + l5_enabled = 1;
> + free(string);
> + } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
> + readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
> + &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
> + FAULT_ON_ERROR);
> +
> + if (l5_enabled)
> + machdep->flags |= VM_5LEVEL;
> + }
I'll fix that and retest.
It still fails on 4.17 and later kernels that have this in their VMCOREINFO:
NUMBER(pgtable_l5_enabled)=0
You need to do atoi(string) to get its value. I'll fix that and retest again...
Dave
Thanks,
Dave
----- Original Message -----
> Currently, Crash only enable support for kernel-only 5-level page tables by
> entering the command line option "--machdep vm=5level". Since Linux 4.17,
> the Linux kernel can be both 4level and 5level page tables. This command
> line
> can't work well for this.
>
> Using the "pgtable_l5_enabled" to detect whether the kernel proper for 5
> level
> page tables automatically. Also move the 5-level paging setup from
> machdep_init(PRE_GDB)
> to machdep_init(POST_RELOC).
>
> Signed-off-by: Dave Anderson <anderson(a)redhat.com>
> Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
> ---
> Changelog v1 --> v2
>
> 1. Make it support live systems suggested by Dave
> 2. Using __pgtable_l5_enabled for check.
> 3. Do some tests in both kdump(5level and 4level) and virsh dump(5level
> and
> 4level)
> ---
> x86_64.c | 56 +++++++++++++++++++++++++++++++++++++-------------------
> 1 file changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/x86_64.c b/x86_64.c
> index 6d1ae2f..07b6aa9 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -294,25 +294,6 @@ x86_64_init(int when)
> machdep->machspec->pgdir_shift = PGDIR_SHIFT;
> machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD;
> break;
> -
> - case VM_5LEVEL:
> - machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
> - machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
> - machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
> - machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
> - machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
> - machdep->machspec->modules_end = MODULES_END_5LEVEL;
> - machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
> - machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
> - if (symbol_exists("vmemmap_populate"))
> - machdep->flags |= VMEMMAP;
> - machdep->machspec->physical_mask_shift = __PHYSICAL_MASK_SHIFT_5LEVEL;
> - machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
> - machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
> - if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
> - error(FATAL, "cannot malloc p4d space.");
> - machdep->machspec->last_p4d_read = 0;
> - machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional per-task
> */
> }
> machdep->kvbase = (ulong)PAGE_OFFSET;
> machdep->identity_map_base = (ulong)PAGE_OFFSET;
> @@ -346,6 +327,43 @@ x86_64_init(int when)
> break;
>
> case POST_RELOC:
> + /* Check for 5-level paging */
> + if (!(machdep->flags & VM_5LEVEL)) {
> + int l5_enabled;
> + if ((string = pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)")))
{
> + l5_enabled = 1;
> + free(string);
> + } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
> + readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
> + &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
> + FAULT_ON_ERROR);
> +
> + if (l5_enabled)
> + machdep->flags |= VM_5LEVEL;
> + }
> + if (machdep->flags & VM_5LEVEL) {
> + machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
> + machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
> + machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
> + machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
> + machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
> + machdep->machspec->modules_end = MODULES_END_5LEVEL;
> + machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
> + machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
> + if (symbol_exists("vmemmap_populate"))
> + machdep->flags |= VMEMMAP;
> + machdep->machspec->physical_mask_shift = __PHYSICAL_MASK_SHIFT_5LEVEL;
> + machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
> + machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
> + if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
> + error(FATAL, "cannot malloc p4d space.");
> + machdep->machspec->last_p4d_read = 0;
> + machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional per-task
> */
> + machdep->kvbase = (ulong)PAGE_OFFSET;
> + machdep->identity_map_base = (ulong)PAGE_OFFSET;
> +
> + }
> +
> /*
> * Check for CONFIG_RANDOMIZE_MEMORY, and set page_offset here.
> * The remainder of the virtual address range setups will get
> --
> 2.14.3
>
>
>
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2:33 p.m.
----- Original Message -----
----- Original Message -----
>
> Hello Dou,
>
> This patch was failing on most -- but not all -- of my test dumpfiles, because of
> fatal read or seek errors during session initialization.
>
> As it turns out, the "l5_enabled" local variable needs to be zeroed-out,
because
> if neither the "if" or the "else" are true, it uses whatever old
stack garbage
> that l5_enabled contains:
>
> > + /* Check for 5-level paging */
> > + if (!(machdep->flags & VM_5LEVEL)) {
> > + int l5_enabled;
> > + if ((string =
pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)"))) {
> > + l5_enabled = 1;
> > + free(string);
> > + } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
> > + readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
> > + &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
> > + FAULT_ON_ERROR);
> > +
> > + if (l5_enabled)
> > + machdep->flags |= VM_5LEVEL;
> > + }
>
> I'll fix that and retest.
It still fails on 4.17 and later kernels that have this in their VMCOREINFO:
NUMBER(pgtable_l5_enabled)=0
You need to do atoi(string) to get its value. I'll fix that and retest
again...
Dave
Hi Dou,
The updated patch is queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/b21633026a725a10b9394aabc65...
Thanks for all your help in implementing this support -- it is much appreciated.
The final phase of support would be making this work:
static int
x86_64_task_uses_5level(struct task_context *tc)
{
return FALSE;
}
Have you had a chance to look at how that can be done?
Thanks,
Dave
>
> Thanks,
> Dave
>
>
>
>
>
> ----- Original Message -----
> > Currently, Crash only enable support for kernel-only 5-level page tables
> > by
> > entering the command line option "--machdep vm=5level". Since Linux
4.17,
> > the Linux kernel can be both 4level and 5level page tables. This command
> > line
> > can't work well for this.
> >
> > Using the "pgtable_l5_enabled" to detect whether the kernel proper
for 5
> > level
> > page tables automatically. Also move the 5-level paging setup from
> > machdep_init(PRE_GDB)
> > to machdep_init(POST_RELOC).
> >
> > Signed-off-by: Dave Anderson <anderson(a)redhat.com>
> > Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
> > ---
> > Changelog v1 --> v2
> >
> > 1. Make it support live systems suggested by Dave
> > 2. Using __pgtable_l5_enabled for check.
> > 3. Do some tests in both kdump(5level and 4level) and virsh dump(5level
> > and
> > 4level)
> > ---
> > x86_64.c | 56 +++++++++++++++++++++++++++++++++++++-------------------
> > 1 file changed, 37 insertions(+), 19 deletions(-)
> >
> > diff --git a/x86_64.c b/x86_64.c
> > index 6d1ae2f..07b6aa9 100644
> > --- a/x86_64.c
> > +++ b/x86_64.c
> > @@ -294,25 +294,6 @@ x86_64_init(int when)
> > machdep->machspec->pgdir_shift = PGDIR_SHIFT;
> > machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD;
> > break;
> > -
> > - case VM_5LEVEL:
> > - machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
> > - machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
> > - machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
> > - machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
> > - machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
> > - machdep->machspec->modules_end = MODULES_END_5LEVEL;
> > - machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
> > - machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
> > - if (symbol_exists("vmemmap_populate"))
> > - machdep->flags |= VMEMMAP;
> > - machdep->machspec->physical_mask_shift =
> > __PHYSICAL_MASK_SHIFT_5LEVEL;
> > - machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
> > - machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
> > - if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
> > - error(FATAL, "cannot malloc p4d space.");
> > - machdep->machspec->last_p4d_read = 0;
> > - machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional
> > per-task
> > */
> > }
> > machdep->kvbase = (ulong)PAGE_OFFSET;
> > machdep->identity_map_base = (ulong)PAGE_OFFSET;
> > @@ -346,6 +327,43 @@ x86_64_init(int when)
> > break;
> >
> > case POST_RELOC:
> > + /* Check for 5-level paging */
> > + if (!(machdep->flags & VM_5LEVEL)) {
> > + int l5_enabled;
> > + if ((string =
pc->read_vmcoreinfo("NUMBER(pgtable_l5_enabled)"))) {
> > + l5_enabled = 1;
> > + free(string);
> > + } else if (kernel_symbol_exists("__pgtable_l5_enabled"))
> > + readmem(symbol_value("__pgtable_l5_enabled"), KVADDR,
> > + &l5_enabled, sizeof(int), "__pgtable_l5_enabled",
> > + FAULT_ON_ERROR);
> > +
> > + if (l5_enabled)
> > + machdep->flags |= VM_5LEVEL;
> > + }
> > + if (machdep->flags & VM_5LEVEL) {
> > + machdep->machspec->userspace_top = USERSPACE_TOP_5LEVEL;
> > + machdep->machspec->page_offset = PAGE_OFFSET_5LEVEL;
> > + machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_5LEVEL;
> > + machdep->machspec->vmalloc_end = VMALLOC_END_5LEVEL;
> > + machdep->machspec->modules_vaddr = MODULES_VADDR_5LEVEL;
> > + machdep->machspec->modules_end = MODULES_END_5LEVEL;
> > + machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_5LEVEL;
> > + machdep->machspec->vmemmap_end = VMEMMAP_END_5LEVEL;
> > + if (symbol_exists("vmemmap_populate"))
> > + machdep->flags |= VMEMMAP;
> > + machdep->machspec->physical_mask_shift =
> > __PHYSICAL_MASK_SHIFT_5LEVEL;
> > + machdep->machspec->pgdir_shift = PGDIR_SHIFT_5LEVEL;
> > + machdep->machspec->ptrs_per_pgd = PTRS_PER_PGD_5LEVEL;
> > + if ((machdep->machspec->p4d = (char *)malloc(PAGESIZE())) == NULL)
> > + error(FATAL, "cannot malloc p4d space.");
> > + machdep->machspec->last_p4d_read = 0;
> > + machdep->uvtop = x86_64_uvtop_level4; /* 5-level is optional
> > per-task
> > */
> > + machdep->kvbase = (ulong)PAGE_OFFSET;
> > + machdep->identity_map_base = (ulong)PAGE_OFFSET;
> > +
> > + }
> > +
> > /*
> > * Check for CONFIG_RANDOMIZE_MEMORY, and set page_offset here.
> > * The remainder of the virtual address range setups will get
> > --
> > 2.14.3
> >
> >
> >
> >
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
10:12 p.m.
Hi Dave,
At 07/11/2018 03:33 AM, Dave Anderson wrote:
The final phase of support would be making this work:
static int
x86_64_task_uses_5level(struct task_context *tc)
{
return FALSE;
}
Have you had a chance to look at how that can be done?
I have no idea to check if 5level paging is used in User-space.
You gave me some methods, and I have try:
-The MAP_FIXED flag
-check if the contents of the page directory or p4d is 'flods'
Now, I found a rough way. As We all know, in x86_64_uvtop_level4(),
the user virtual address is either 4-level or 5-level paging. Can we
do like that:
if (machdep->flags & VM_5LEVEL)
1) Using 5-level parsing code...
2) Check if it is success
If failed, Using 4-level parsing code...
else
Always using 4-level parsing code...
3) go on...
Thanks,
dou
--------------8<----------------
diff --git a/x86_64.c b/x86_64.c
index 07b6aa9..0e12825 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -1915,22 +1915,21 @@ x86_64_uvtop_level4(struct task_context *tc,
ulong uvaddr, physaddr_t *paddr, in
goto no_upage;
/* If the VM is in 5-level page table */
- if (machdep->flags & VM_5LEVEL && x86_64_task_uses_5level(tc)) {
+ if (machdep->flags & VM_5LEVEL) {
ulong p4d_pte;
/*
* p4d = p4d_offset(pgd, address);
*/
p4d_pte = x86_64_p4d_offset(pgd_pte, uvaddr, verbose,
FALSE);
- if (!(p4d_pte & _PAGE_PRESENT))
- goto no_upage;
- /*
- * pud = pud_offset(p4d, address);
- */
- pud_pte = x86_64_pud_offset(p4d_pte, uvaddr, verbose,
FALSE);
+ if (!(p4d_pte & _PAGE_PRESENT)) {
+ /* pud = pud_offset(pgd, address); */
+ pud_pte = x86_64_pud_offset(pgd_pte, uvaddr,
verbose, FALSE);
+ } else {
+ /* pud = pud_offset(p4d, address); */
+ pud_pte = x86_64_pud_offset(p4d_pte, uvaddr,
verbose, FALSE);
+ }
} else {
- /*
- * pud = pud_offset(pgd, address);
- */
+ /* pud = pud_offset(pgd, address); */
pud_pte = x86_64_pud_offset(pgd_pte, uvaddr, verbose,
FALSE);
}
9:02 a.m.
----- Original Message -----
Hi Dave,
At 07/11/2018 03:33 AM, Dave Anderson wrote:
>
> The final phase of support would be making this work:
>
> static int
> x86_64_task_uses_5level(struct task_context *tc)
> {
> return FALSE;
> }
>
> Have you had a chance to look at how that can be done?
>
I have no idea to check if 5level paging is used in User-space.
You gave me some methods, and I have try:
-The MAP_FIXED flag
-check if the contents of the page directory or p4d is 'flods'
It would be most helpful if you can compare two tasks, one with 5-level
and one without, and see if there's anything obviously different.
(I don't know what "flods" means)
The documentation in 5level-paging.txt is not very clear, but it does
state that MAP_FIXED is not required:
But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.
If hint address set above 47-bit, but MAP_FIXED is not specified, we try
to look for unmapped area by specified address. If it's already
occupied, we look for unmapped area in *full* address space, rather than
from 47-bit window.
That seems to imply that when the kernel is using 5-level page tables,
then the user-space tasks are also using them -- regardless whether
the task has requested an allocation or not. In other words, if a task
that is already running requests memory in the high address space, its
page tables have already been set up. I wouldn't think that an mmap()
request could change the top-level page table mappings on the fly,
correct?
Now, I found a rough way. As We all know, in x86_64_uvtop_level4(),
the user virtual address is either 4-level or 5-level paging. Can we
do like that:
if (machdep->flags & VM_5LEVEL)
1) Using 5-level parsing code...
2) Check if it is success
If failed, Using 4-level parsing code...
else
Always using 4-level parsing code...
3) go on...
Have you actually confirmed that a user task using 4-level page tables
will fail "vtop" or "vm -p" if the kernel is running with 5-level
page
tables?
Dave
1:23 p.m.
----- Original Message -----
----- Original Message -----
> Hi Dave,
>
> At 07/11/2018 03:33 AM, Dave Anderson wrote:
> >
> > The final phase of support would be making this work:
> >
> > static int
> > x86_64_task_uses_5level(struct task_context *tc)
> > {
> > return FALSE;
> > }
> >
> > Have you had a chance to look at how that can be done?
> >
>
> I have no idea to check if 5level paging is used in User-space.
>
> You gave me some methods, and I have try:
>
> -The MAP_FIXED flag
> -check if the contents of the page directory or p4d is 'flods'
It would be most helpful if you can compare two tasks, one with 5-level
and one without, and see if there's anything obviously different.
(I don't know what "flods" means)
Ah, sorry, you mean if the top-level page directory folds back into itself.
So yes, I wonder if it would be obvious enough by checking whether the
top-level pgd folds back into itself, and if so, 4-levels of page tables
are in use? But if that were the case, it seems that the 5-level translation
code would work on both types of user-space tasks. I just don't understand
how it's supposed to work.
Dave
The documentation in 5level-paging.txt is not very clear, but it does
state that MAP_FIXED is not required:
But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.
If hint address set above 47-bit, but MAP_FIXED is not specified, we try
to look for unmapped area by specified address. If it's already
occupied, we look for unmapped area in *full* address space, rather than
from 47-bit window.
That seems to imply that when the kernel is using 5-level page tables,
then the user-space tasks are also using them -- regardless whether
the task has requested an allocation or not. In other words, if a task
that is already running requests memory in the high address space, its
page tables have already been set up. I wouldn't think that an mmap()
request could change the top-level page table mappings on the fly,
correct?
> Now, I found a rough way. As We all know, in x86_64_uvtop_level4(),
> the user virtual address is either 4-level or 5-level paging. Can we
> do like that:
>
> if (machdep->flags & VM_5LEVEL)
> 1) Using 5-level parsing code...
> 2) Check if it is success
> If failed, Using 4-level parsing code...
> else
> Always using 4-level parsing code...
>
> 3) go on...
Have you actually confirmed that a user task using 4-level page tables
will fail "vtop" or "vm -p" if the kernel is running with 5-level
page
tables?
Dave
7:02 a.m.
At 07/12/2018 02:23 AM, Dave Anderson wrote:
----- Original Message -----
>
>
> ----- Original Message -----
>> Hi Dave,
>>
>> At 07/11/2018 03:33 AM, Dave Anderson wrote:
>>>
>>> The final phase of support would be making this work:
>>>
>>> static int
>>> x86_64_task_uses_5level(struct task_context *tc)
>>> {
>>> return FALSE;
>>> }
>>>
>>> Have you had a chance to look at how that can be done?
>>>
>>
>> I have no idea to check if 5level paging is used in User-space.
>>
>> You gave me some methods, and I have try:
>>
>> -The MAP_FIXED flag
>> -check if the contents of the page directory or p4d is 'flods'
>
> It would be most helpful if you can compare two tasks, one with 5-level
> and one without, and see if there's anything obviously different.
> (I don't know what "flods" means)
Ah, sorry, you mean if the top-level page directory folds back into itself.
So yes, I wonder if it would be obvious enough by checking whether the
top-level pgd folds back into itself, and if so, 4-levels of page tables
are in use? But if that were the case, it seems that the 5-level translation
code would work on both types of user-space tasks. I just don't understand
how it's supposed to work.
OK, let me try to clarify if the the 5-level translation code would work
on both types of user-space tasks at first. ;-)
Thank you so much for you kind explanation!
dou.
Dave
>
> The documentation in 5level-paging.txt is not very clear, but it does
> state that MAP_FIXED is not required:
>
> But userspace can ask for allocation from full address space by
> specifying hint address (with or without MAP_FIXED) above 47-bits.
>
> If hint address set above 47-bit, but MAP_FIXED is not specified, we try
> to look for unmapped area by specified address. If it's already
> occupied, we look for unmapped area in *full* address space, rather than
> from 47-bit window.
>
> That seems to imply that when the kernel is using 5-level page tables,
> then the user-space tasks are also using them -- regardless whether
> the task has requested an allocation or not. In other words, if a task
> that is already running requests memory in the high address space, its
> page tables have already been set up. I wouldn't think that an mmap()
> request could change the top-level page table mappings on the fly,
> correct?
>
>> Now, I found a rough way. As We all know, in x86_64_uvtop_level4(),
>> the user virtual address is either 4-level or 5-level paging. Can we
>> do like that:
>>
>> if (machdep->flags & VM_5LEVEL)
>> 1) Using 5-level parsing code...
>> 2) Check if it is success
>> If failed, Using 4-level parsing code...
>> else
>> Always using 4-level parsing code...
>>
>> 3) go on...
>
> Have you actually confirmed that a user task using 4-level page tables
> will fail "vtop" or "vm -p" if the kernel is running with 5-level
page
> tables?
>
> Dave
>
>
>
8:08 a.m.
----- Original Message -----
At 07/12/2018 02:23 AM, Dave Anderson wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> Hi Dave,
>>>
>>> At 07/11/2018 03:33 AM, Dave Anderson wrote:
>>>>
>>>> The final phase of support would be making this work:
>>>>
>>>> static int
>>>> x86_64_task_uses_5level(struct task_context *tc)
>>>> {
>>>> return FALSE;
>>>> }
>>>>
>>>> Have you had a chance to look at how that can be done?
>>>>
>>>
>>> I have no idea to check if 5level paging is used in User-space.
>>>
>>> You gave me some methods, and I have try:
>>>
>>> -The MAP_FIXED flag
>>> -check if the contents of the page directory or p4d is 'flods'
>>
>> It would be most helpful if you can compare two tasks, one with 5-level
>> and one without, and see if there's anything obviously different.
>> (I don't know what "flods" means)
>
> Ah, sorry, you mean if the top-level page directory folds back into itself.
>
> So yes, I wonder if it would be obvious enough by checking whether the
> top-level pgd folds back into itself, and if so, 4-levels of page tables
> are in use? But if that were the case, it seems that the 5-level translation
> code would work on both types of user-space tasks. I just don't understand
> how it's supposed to work.
>
OK, let me try to clarify if the the 5-level translation code would work
on both types of user-space tasks at first. ;-)
Thank you so much for you kind explanation!
dou.
Hi Dou,
That leads me to this question: can you confirm that this crash patch
works with a kernel that is configured with CONFIG_X86_5LEVEL, but either:
(1) the kernel was booted with "no5lvl", or
(2) the host hardware does not have the X86_CR4_LA57 bit set
Thanks,
Dave
10:23 p.m.
At 07/12/2018 09:08 PM, Dave Anderson wrote:
----- Original Message -----
>
>
> At 07/12/2018 02:23 AM, Dave Anderson wrote:
>>
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> Hi Dave,
>>>>
>>>> At 07/11/2018 03:33 AM, Dave Anderson wrote:
>>>>>
>>>>> The final phase of support would be making this work:
>>>>>
>>>>> static int
>>>>> x86_64_task_uses_5level(struct task_context *tc)
>>>>> {
>>>>> return FALSE;
>>>>> }
>>>>>
>>>>> Have you had a chance to look at how that can be done?
>>>>>
>>>>
>>>> I have no idea to check if 5level paging is used in User-space.
>>>>
>>>> You gave me some methods, and I have try:
>>>>
>>>> -The MAP_FIXED flag
>>>> -check if the contents of the page directory or p4d is
'flods'
>>>
>>> It would be most helpful if you can compare two tasks, one with 5-level
>>> and one without, and see if there's anything obviously different.
>>> (I don't know what "flods" means)
>>
>> Ah, sorry, you mean if the top-level page directory folds back into itself.
>>
>> So yes, I wonder if it would be obvious enough by checking whether the
>> top-level pgd folds back into itself, and if so, 4-levels of page tables
>> are in use? But if that were the case, it seems that the 5-level translation
>> code would work on both types of user-space tasks. I just don't understand
>> how it's supposed to work.
>>
>
> OK, let me try to clarify if the the 5-level translation code would work
> on both types of user-space tasks at first. ;-)
>
Hi Dave,
As we all know, the kernel with CONFIG_X86_5LEVEL=y can run both in the
4-level page table and 5-level page table. It's configured by:
- no5lvl in cmdline
- the machine supports 5-level paging
- CPUID leaf 7 is supported
- the leaf has the feature bit set
then, Kernel using the __pgtable_l5_enabled to record the last result.
In the Documentation/x86/x86_64/5level-paging.txt:
...
To mitigate this, we are not going to allocate virtual address space
above 47-bit by default.
But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.
...
IMO, the document only tell us that some user tasks can't using the
address above 47-bits, this doesn't effect the paging level.
So, I think we don't need to add check for user tasks, in other word,
All user tasks must using 5-level paging if __pgtable_l5_enabled = 1.
Correct?
BTW, I will try to ask Kirill about it and will cc you. OK? ;-)
> Thank you so much for you kind explanation!
>
> dou.
Hi Dou,
That leads me to this question: can you confirm that this crash patch
works with a kernel that is configured with CONFIG_X86_5LEVEL, but either:
(1) the kernel was booted with "no5lvl", or
(2) the host hardware does not have the X86_CR4_LA57 bit set
I tested the two cases with the following patch, 'vm -p' and 'kmem -v'
shows OK.
---------------------------8<------------------------------------------
Author: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
Date: Fri Jul 13 10:43:26 2018 +0800
x86_64: Remove the unused x86_64_task_uses_5level()
diff --git a/x86_64.c b/x86_64.c
index b07d6f2..96f685b 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -24,7 +24,6 @@ static int x86_64_uvtop(struct task_context *, ulong,
physaddr_t *, int);
static int x86_64_uvtop_level4(struct task_context *, ulong,
physaddr_t *, int);
static int x86_64_uvtop_level4_xen_wpt(struct task_context *, ulong,
physaddr_t *, int);
static int x86_64_uvtop_level4_rhel4_xen_wpt(struct task_context *,
ulong, physaddr_t *, int);
-static int x86_64_task_uses_5level(struct task_context *);
static ulong x86_64_vmalloc_start(void);
static int x86_64_is_task_addr(ulong);
static int x86_64_verify_symbol(const char *, ulong, char);
@@ -341,6 +340,7 @@ x86_64_init(int when)
if (l5_enabled)
machdep->flags |= VM_5LEVEL;
}
+
if (machdep->flags & VM_5LEVEL) {
machdep->machspec->userspace_top =
USERSPACE_TOP_5LEVEL;
machdep->machspec->page_offset =
PAGE_OFFSET_5LEVEL;
@@ -361,7 +361,6 @@ x86_64_init(int when)
machdep->uvtop = x86_64_uvtop_level4; /*
5-level is optional per-task */
machdep->kvbase = (ulong)PAGE_OFFSET;
machdep->identity_map_base = (ulong)PAGE_OFFSET;
-
}
/*
@@ -1915,7 +1914,7 @@ x86_64_uvtop_level4(struct task_context *tc, ulong
uvaddr, physaddr_t *paddr, in
goto no_upage;
/* If the VM is in 5-level page table */
- if (machdep->flags & VM_5LEVEL && x86_64_task_uses_5level(tc)) {
+ if (machdep->flags & VM_5LEVEL) {
ulong p4d_pte;
/*
* p4d = p4d_offset(pgd, address);
@@ -1986,12 +1985,6 @@ no_upage:
return FALSE;
}
-static int
-x86_64_task_uses_5level(struct task_context *tc)
-{
- return FALSE;
-}
-
static int
x86_64_uvtop_level4_xen_wpt(struct task_context *tc, ulong uvaddr,
physaddr_t *paddr, int verbose)
{
Thanks,
Dave
9:31 a.m.
----- Original Message -----
At 07/12/2018 09:08 PM, Dave Anderson wrote:
>
>
> ----- Original Message -----
>>
>>
>> At 07/12/2018 02:23 AM, Dave Anderson wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> Hi Dave,
>>>>>
>>>>> At 07/11/2018 03:33 AM, Dave Anderson wrote:
>>>>>>
>>>>>> The final phase of support would be making this work:
>>>>>>
>>>>>> static int
>>>>>> x86_64_task_uses_5level(struct task_context *tc)
>>>>>> {
>>>>>> return FALSE;
>>>>>> }
>>>>>>
>>>>>> Have you had a chance to look at how that can be done?
>>>>>>
>>>>>
>>>>> I have no idea to check if 5level paging is used in User-space.
>>>>>
>>>>> You gave me some methods, and I have try:
>>>>>
>>>>> -The MAP_FIXED flag
>>>>> -check if the contents of the page directory or p4d is
'flods'
>>>>
>>>> It would be most helpful if you can compare two tasks, one with 5-level
>>>> and one without, and see if there's anything obviously different.
>>>> (I don't know what "flods" means)
>>>
>>> Ah, sorry, you mean if the top-level page directory folds back into
>>> itself.
>>>
>>> So yes, I wonder if it would be obvious enough by checking whether the
>>> top-level pgd folds back into itself, and if so, 4-levels of page tables
>>> are in use? But if that were the case, it seems that the 5-level
>>> translation
>>> code would work on both types of user-space tasks. I just don't
>>> understand
>>> how it's supposed to work.
>>>
>>
>> OK, let me try to clarify if the the 5-level translation code would work
>> on both types of user-space tasks at first. ;-)
>>
Hi Dave,
As we all know, the kernel with CONFIG_X86_5LEVEL=y can run both in the
4-level page table and 5-level page table. It's configured by:
- no5lvl in cmdline
- the machine supports 5-level paging
- CPUID leaf 7 is supported
- the leaf has the feature bit set
then, Kernel using the __pgtable_l5_enabled to record the last result.
In the Documentation/x86/x86_64/5level-paging.txt:
...
To mitigate this, we are not going to allocate virtual address space
above 47-bit by default.
But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.
...
IMO, the document only tell us that some user tasks can't using the
address above 47-bits, this doesn't effect the paging level.
So, I think we don't need to add check for user tasks, in other word,
All user tasks must using 5-level paging if __pgtable_l5_enabled = 1.
Correct?
That make sense, and sounds good to me!
BTW, I will try to ask Kirill about it and will cc you. OK? ;-)
OK thanks,
Dave
>> Thank you so much for you kind explanation!
>>
>> dou.
>
> Hi Dou,
>
> That leads me to this question: can you confirm that this crash patch
> works with a kernel that is configured with CONFIG_X86_5LEVEL, but either:
>
> (1) the kernel was booted with "no5lvl", or
> (2) the host hardware does not have the X86_CR4_LA57 bit set
>
I tested the two cases with the following patch, 'vm -p' and 'kmem -v'
shows OK.
---------------------------8<------------------------------------------
Author: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
Date: Fri Jul 13 10:43:26 2018 +0800
x86_64: Remove the unused x86_64_task_uses_5level()
diff --git a/x86_64.c b/x86_64.c
index b07d6f2..96f685b 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -24,7 +24,6 @@ static int x86_64_uvtop(struct task_context *, ulong,
physaddr_t *, int);
static int x86_64_uvtop_level4(struct task_context *, ulong,
physaddr_t *, int);
static int x86_64_uvtop_level4_xen_wpt(struct task_context *, ulong,
physaddr_t *, int);
static int x86_64_uvtop_level4_rhel4_xen_wpt(struct task_context *,
ulong, physaddr_t *, int);
-static int x86_64_task_uses_5level(struct task_context *);
static ulong x86_64_vmalloc_start(void);
static int x86_64_is_task_addr(ulong);
static int x86_64_verify_symbol(const char *, ulong, char);
@@ -341,6 +340,7 @@ x86_64_init(int when)
if (l5_enabled)
machdep->flags |= VM_5LEVEL;
}
+
if (machdep->flags & VM_5LEVEL) {
machdep->machspec->userspace_top =
USERSPACE_TOP_5LEVEL;
machdep->machspec->page_offset =
PAGE_OFFSET_5LEVEL;
@@ -361,7 +361,6 @@ x86_64_init(int when)
machdep->uvtop = x86_64_uvtop_level4; /*
5-level is optional per-task */
machdep->kvbase = (ulong)PAGE_OFFSET;
machdep->identity_map_base = (ulong)PAGE_OFFSET;
-
}
/*
@@ -1915,7 +1914,7 @@ x86_64_uvtop_level4(struct task_context *tc, ulong
uvaddr, physaddr_t *paddr, in
goto no_upage;
/* If the VM is in 5-level page table */
- if (machdep->flags & VM_5LEVEL && x86_64_task_uses_5level(tc)) {
+ if (machdep->flags & VM_5LEVEL) {
ulong p4d_pte;
/*
* p4d = p4d_offset(pgd, address);
@@ -1986,12 +1985,6 @@ no_upage:
return FALSE;
}
-static int
-x86_64_task_uses_5level(struct task_context *tc)
-{
- return FALSE;
-}
-
static int
x86_64_uvtop_level4_xen_wpt(struct task_context *tc, ulong uvaddr,
physaddr_t *paddr, int verbose)
{
> Thanks,
> Dave
>
>
>
>
>
6:56 a.m.
Hi Dave,
At 07/11/2018 10:02 PM, Dave Anderson wrote:
----- Original Message -----
> Hi Dave,
>
> At 07/11/2018 03:33 AM, Dave Anderson wrote:
>>
>> The final phase of support would be making this work:
>>
>> static int
>> x86_64_task_uses_5level(struct task_context *tc)
>> {
>> return FALSE;
>> }
>>
>> Have you had a chance to look at how that can be done?
>>
>
> I have no idea to check if 5level paging is used in User-space.
>
> You gave me some methods, and I have try:
>
> -The MAP_FIXED flag
> -check if the contents of the page directory or p4d is 'flods'
It would be most helpful if you can compare two tasks, one with 5-level
and one without, and see if there's anything obviously different.
OK, I will compare them carefully.
(I don't know what "flods" means)
The documentation in 5level-paging.txt is not very clear, but it does
state that MAP_FIXED is not required:
But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.
If hint address set above 47-bit, but MAP_FIXED is not specified, we try
to look for unmapped area by specified address. If it's already
occupied, we look for unmapped area in *full* address space, rather than
from 47-bit window.
That seems to imply that when the kernel is using 5-level page tables,
then the user-space tasks are also using them -- regardless whether
Yes, I agree.
the task has requested an allocation or not. In other words, if a
task
that is already running requests memory in the high address space, its
page tables have already been set up. I wouldn't think that an mmap()
request could change the top-level page table mappings on the fly,
correct?
Did you mean that we actually don't need to do x86_64_task_uses_5level()
in user task?
> Now, I found a rough way. As We all know, in x86_64_uvtop_level4(),
> the user virtual address is either 4-level or 5-level paging. Can we
> do like that:
>
> if (machdep->flags & VM_5LEVEL)
> 1) Using 5-level parsing code...
> 2) Check if it is success
> If failed, Using 4-level parsing code...
> else
> Always using 4-level parsing code...
>
> 3) go on...
Have you actually confirmed that a user task using 4-level page tables
will fail "vtop" or "vm -p" if the kernel is running with 5-level
page
tables?
Actually, I can't found a user task using 4-leve paging in the kernel
which is running with 5-level page tables. Do you have some examples?
Let me investigate more.
Thank,
dou
Dave
2328
days inactive
2331
days old
devel@lists.crash-utility.osci.io
11 comments
2 participants
participants (2)
-
Dave Anderson -
Dou Liyang