3:21 a.m.
Hi, Johan
Thanks for the fix.
在 2021年03月12日 01:00, crash-utility-request(a)redhat.com 写道:
Date: Thu, 11 Mar 2021 08:54:30 +0000
From: <Johan.Erlandsson(a)sony.com>
To: <crash-utility(a)redhat.com>
Subject: [Crash-utility] [PATCH] arm64: handle 1GB block
Message-ID:
<AM0P193MB06428B158EE504FE3466B105E3909(a)AM0P193MB0642.EURP193.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="us-ascii"
With enough continuous physical memory we can have 1GB block. This have
been seen only in linear mapping region in kernel space. I have only
verified this for VM_L3_4K.
reference: alloc_init_pud(), use_1G_block() [arch/arm64/mm/mmu.c]
For this situation, do you know how to reproduce it easily? Can you share
your steps in detail?
BTW: I did the test, but I didn't enter into the kernel code path because
that condition was not met.
# dmesg|grep -i huge
[ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.0-rc7+
root=/dev/mapper/rhel_gigabyte--r120--20-root ro arm-smmu.disable_bypass=n
initcall_blacklist=gtdt_sbsa_gwdt_init iommu.passthrough=1 crashkernel=512M hugepagesz=1G
hugepages=6 debug_pagealloc=on rd.lvm.lv=rhel_gigabyte-r120-20/root
rd.lvm.lv=rhel_gigabyte-r120-20/swap
[ 2.620634] HugeTLB registered 1.00 GiB page size, pre-allocated 6 pages
Thanks.
Lianbo
This problem can for instance be seen with vtop command, example:
crash> vtop ffffffd988008000
VIRTUAL PHYSICAL
ffffffd988008000 148008000
PAGE DIRECTORY: ffffff9188c6c000
PGD: ffffff9188c6cb30 => 68000140000711
PMD: ffffffd980000200 => aa0003e2b9402fe1
PAGE: 3e2b9400000 (2MB)
PTE PHYSICAL FLAGS
aa0003e2b9402fe1 3e2b9402000 (VALID|USER|RDONLY|SHARED|AF|NG)
---
arm64.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arm64.c b/arm64.c
index 37aed07..4787fa6 100644
--- a/arm64.c
+++ b/arm64.c
@@ -1260,11 +1260,14 @@ arm64_uvtop(struct task_context *tc, ulong uvaddr, physaddr_t
*paddr, int verbos
#define PTE_TO_PHYS(pteval) (machdep->max_physmem_bits == 52 ? \
(((pteval & PTE_ADDR_LOW) | ((pteval & PTE_ADDR_HIGH) << 36))) :
(pteval & PTE_ADDR_LOW))
+#define PUD_TYPE_MASK 3
+#define PUD_TYPE_SECT 1
#define PMD_TYPE_MASK 3
#define PMD_TYPE_SECT 1
#define PMD_TYPE_TABLE 2
#define SECTION_PAGE_MASK_2MB ((long)(~((MEGABYTES(2))-1)))
#define SECTION_PAGE_MASK_512MB ((long)(~((MEGABYTES(512))-1)))
+#define SECTION_PAGE_MASK_1GB ((long)(~((GIGABYTES(1))-1)))
static int
arm64_vtop_2level_64k(ulong pgd, ulong vaddr, physaddr_t *paddr, int verbose)
@@ -1420,6 +1423,15 @@ arm64_vtop_3level_4k(ulong pgd, ulong vaddr, physaddr_t *paddr,
int verbose)
if (!pgd_val)
goto no_page;
+ if ((pgd_val & PUD_TYPE_MASK) == PUD_TYPE_SECT) {
+ ulong sectionbase = (pgd_val & SECTION_PAGE_MASK_1GB) &
PHYS_MASK;
+ if (verbose) {
+ fprintf(fp, " PAGE: %lx (1GB)\n\n", sectionbase);
+ arm64_translate_pte(pgd_val, 0, 0);
+ }
+ *paddr = sectionbase + (vaddr & ~SECTION_PAGE_MASK_1GB);
+ return TRUE;
+ }
/*
* #define __PAGETABLE_PUD_FOLDED
*/
-- 2.17.1
4:25 a.m.
New subject: [PATCH] arm64: handle 1GB block
Hi Lianbo
>
> With enough continuous physical memory we can have 1GB block. This have
> been seen only in linear mapping region in kernel space. I have only
> verified this for VM_L3_4K.
>
> reference: alloc_init_pud(), use_1G_block() [arch/arm64/mm/mmu.c]
>
For this situation, do you know how to reproduce it easily? Can you share
your steps in detail?
I can try, one requirement is that you have memory aligned at 1 GB and
size is at least 1 GB. Lets assume we have vmcore with physical memory
at 0x100000000 (1 GB aligned) with size at least 1 GB. Then from crash we
could do:
crash> ptov 100000000
VIRTUAL PHYSICAL
ffffffe900000000 100000000
crash> vtop ffffffe900000000
VIRTUAL PHYSICAL
ffffffe900000000 100000000
PAGE DIRECTORY: ffffff990f66c000
PGD: ffffff990f66cd20 => 68000100000711
PAGE: 100000000 (1GB)
PTE PHYSICAL FLAGS
68000100000711 100000000 (VALID|SHARED|AF|PXN|UXN)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffffbfa4000000 100000000 ffffffe97de59090 fe 2 20054
uptodate,lru,workingset,mappedtodisk
I hope that helps.
Regards
Johan
BTW: I did the test, but I didn't enter into the kernel code path
because
that condition was not met.
# dmesg|grep -i huge
[ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.0-rc7+
root=/dev/mapper/rhel_gigabyte--r120--20-root ro arm->smmu.disable_bypass=n
initcall_blacklist=gtdt_sbsa_gwdt_init iommu.passthrough=1 crashkernel=512M hugepagesz=1G
hugepages=6 >debug_pagealloc=on rd.lvm.lv=rhel_gigabyte-r120-20/root
rd.lvm.lv=rhel_gigabyte-r120-20/swap
[ 2.620634] HugeTLB registered 1.00 GiB page size, pre-allocated 6 pages
Thanks.
Lianbo
9:51 p.m.
New subject: [PATCH] arm64: handle 1GB block
在 2021年04月16日 17:25, Johan.Erlandsson(a)sony.com 写道:
Hi Lianbo
>>
>> With enough continuous physical memory we can have 1GB block. This have
>> been seen only in linear mapping region in kernel space. I have only
>> verified this for VM_L3_4K.
>>
>> reference: alloc_init_pud(), use_1G_block() [arch/arm64/mm/mmu.c]
>>
> For this situation, do you know how to reproduce it easily? Can you share
> your steps in detail?
I can try, one requirement is that you have memory aligned at 1 GB and
size is at least 1 GB. Lets assume we have vmcore with physical memory
at 0x100000000 (1 GB aligned) with size at least 1 GB. Then from crash we
could do:
Thank you for the explanation, Johan.
I will try to reproduce it later, but anyway, this patch and test are good to me.
Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
crash> ptov 100000000
VIRTUAL PHYSICAL
ffffffe900000000 100000000
crash> vtop ffffffe900000000
VIRTUAL PHYSICAL
ffffffe900000000 100000000
PAGE DIRECTORY: ffffff990f66c000
PGD: ffffff990f66cd20 => 68000100000711
PAGE: 100000000 (1GB)
PTE PHYSICAL FLAGS
68000100000711 100000000 (VALID|SHARED|AF|PXN|UXN)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffffbfa4000000 100000000 ffffffe97de59090 fe 2 20054
uptodate,lru,workingset,mappedtodisk
I hope that helps.
Yes, it certainly helps.
Thanks
Lianbo
Regards
Johan
> BTW: I did the test, but I didn't enter into the kernel code path because
> that condition was not met.
>
> # dmesg|grep -i huge
> [ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.0-rc7+
root=/dev/mapper/rhel_gigabyte--r120--20-root ro arm->smmu.disable_bypass=n
initcall_blacklist=gtdt_sbsa_gwdt_init iommu.passthrough=1 crashkernel=512M hugepagesz=1G
hugepages=6 >debug_pagealloc=on rd.lvm.lv=rhel_gigabyte-r120-20/root
rd.lvm.lv=rhel_gigabyte-r120-20/swap
> [ 2.620634] HugeTLB registered 1.00 GiB page size, pre-allocated 6 pages
>
> Thanks.
> Lianbo
3:15 a.m.
New subject: [PATCH] arm64: handle 1GB block
-----Original Message-----
在 2021年04月16日 17:25, Johan.Erlandsson(a)sony.com 写道:
> Hi Lianbo
>
>>>
>>> With enough continuous physical memory we can have 1GB block. This have
>>> been seen only in linear mapping region in kernel space. I have only
>>> verified this for VM_L3_4K.
>>>
>>> reference: alloc_init_pud(), use_1G_block() [arch/arm64/mm/mmu.c]
>>>
>> For this situation, do you know how to reproduce it easily? Can you share
>> your steps in detail?
>
> I can try, one requirement is that you have memory aligned at 1 GB and
> size is at least 1 GB. Lets assume we have vmcore with physical memory
> at 0x100000000 (1 GB aligned) with size at least 1 GB. Then from crash we
> could do:
>
Thank you for the explanation, Johan.
I will try to reproduce it later, but anyway, this patch and test are good to me.
Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
Thanks, applied:
https://github.com/crash-utility/crash/commit/dccdf95c25234e3573a7a074443...
Kazu
> crash> ptov 100000000
> VIRTUAL PHYSICAL
> ffffffe900000000 100000000
>
> crash> vtop ffffffe900000000
> VIRTUAL PHYSICAL
> ffffffe900000000 100000000
>
> PAGE DIRECTORY: ffffff990f66c000
> PGD: ffffff990f66cd20 => 68000100000711
> PAGE: 100000000 (1GB)
>
> PTE PHYSICAL FLAGS
> 68000100000711 100000000 (VALID|SHARED|AF|PXN|UXN)
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffffbfa4000000 100000000 ffffffe97de59090 fe 2 20054
uptodate,lru,workingset,mappedtodisk
>
> I hope that helps.
> Yes, it certainly helps.
Thanks
Lianbo
> Regards
> Johan
>
>> BTW: I did the test, but I didn't enter into the kernel code path because
>> that condition was not met.
>>
>> # dmesg|grep -i huge
>> [ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.0-rc7+
root=/dev/mapper/rhel_gigabyte--r120--20-root ro arm->smmu.disable_bypass=n
initcall_blacklist=gtdt_sbsa_gwdt_init iommu.passthrough=1 crashkernel=512M hugepagesz=1G
hugepages=6
>debug_pagealloc=on rd.lvm.lv=rhel_gigabyte-r120-20/root
rd.lvm.lv=rhel_gigabyte-r120-20/swap
>> [ 2.620634] HugeTLB registered 1.00 GiB page size, pre-allocated 6 pages
>>
>> Thanks.
>> Lianbo
>
>
>
1174
days inactive
1177
days old
devel@lists.crash-utility.osci.io
3 comments
3 participants
participants (3)
-
HAGIO KAZUHITO(萩尾 一仁) -
Johan.Erlandsson＠sony.com -
lijiang