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,