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,
> 

--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility

Reply via email to