Re: [Crash-utility] increase __PHYSICAL_MASK_SHIFT_XEN?

Hi, Jiri 在 2021年01月22日 20:32, Jiri Bohac 写道: > Hi Lianbo, > >> It's time to update the physical mask for xen, but can you help to >> test the address translation via some command such as vtop, ptov, >> etc? > > you mean with that dump where crash previously failed? Sure. This is the patch Sorry about this. I would suggest to do some tests with your vmcore via these commands: vtop and ptov, maybe that can help to check if the the address translation can work as we expected after applied this patch. > I applied on top of the current git: > > --- a/defs.h > +++ b/defs.h > @@ -3583,7 +3583,7 @@ struct arm64_stackframe { > * PHYSICAL_PAGE_MASK changed (enlarged) between 2.4 and 2.6, so > * for safety, use the 2.6 values to generate it. > */ > -#define __PHYSICAL_MASK_SHIFT_XEN 40 > +#define __PHYSICAL_MASK_SHIFT_XEN 52 > #define __PHYSICAL_MASK_SHIFT_2_6 46 > #define __PHYSICAL_MASK_SHIFT_5LEVEL 52 > #define __PHYSICAL_MASK_SHIFT (machdep->machspec->physical_mask_shift) > > > I can open the dump now: > > $./crash vmcore vmlinux-4.12.14-122.32-default vmlinux-4.12.14-122.32-default.debug > crash 7.2.9++ > Copyright (C) 2002-2020 Red Hat, Inc. > ... > KERNEL: vmlinux-4.12.14-122.32-default > DEBUG KERNEL: vmlinux-4.12.14-122.32-default.debug > DUMPFILE: vmcore [PARTIAL DUMP] > CPUS: 8 [OFFLINE: 7] > DATE: Wed Sep 9 10:16:38 CEST 2020 > UPTIME: 00:28:41 > LOAD AVERAGE: 0.03, 0.05, 0.07 > TASKS: 228 > NODENAME: rsa1419 > RELEASE: 4.12.14-122.32-default > VERSION: #1 SMP Wed Aug 5 12:59:08 UTC 2020 (477c426) > MACHINE: x86_64 (2194 Mhz) > MEMORY: 16 GB > PANIC: "sysrq: SysRq : Trigger a crash" > PID: 7401 > COMMAND: "bash" > TASK: ffff8804590bc200 [THREAD_INFO: ffff8804590bc200] > CPU: 4 > STATE: TASK_RUNNING (SYSRQ) > > crash> p &jiffies > $2 = (volatile unsigned long *) 0xffffffff82005000 <jiffies_64> > crash> vtop 0xffffffff82005000 > VIRTUAL PHYSICAL > ffffffff82005000 2005000 > > PGD DIRECTORY: ffffffff8200a000 > PAGE DIRECTORY: 3003a00e067 [machine] > PGD: 200e000 > PUD: 200eff0 => 3003a00f067 [machine] > PUD: 200f000 > PMD: 200f080 => 3003b2d5067 [machine] > PMD: 32d5000 > PTE: 32d5028 => 801003003a005067 [machine] > PTE: 2005067 > PAGE: 3003a005000 [machine] > PAGE: 2005000 > > PTE PHYSICAL FLAGS > 2005067 2005000 (PRESENT|RW|USER|ACCESSED|DIRTY) > > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > ffffea0000080140 2005000 0 0 1 fffffc0000800 reserved > crash> ptov 2005000 > VIRTUAL PHYSICAL > ffff880002005000 2005000 >

> >> Or follow up the 5-level page changes to check if it has the >> capability(cr4 & CR4_LA57)? > > sorry, I don't understand what you mean; the crashed linux dump contains an oops that shows the CR4 value as > 0000000000040660, i.e. the LA57 bit is not set. > Thanks for the feedback. The guest itself may not support the 5-level paging for your situation according to this commit <6f0e8bf16730>. > Let me know if you want me to try something else. > No other issue for me, only several commands tests mentioned above. Thank you for the help. Lianbo > Thanks, >