[Crash-utility] increase __PHYSICAL_MASK_SHIFT_XEN?

[lijiang]

在 2021年01月25日 18:33, lijiang 写道:
> 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         
>>

OK, I just saw the above vtop and ptov commands tests, please ignore the last reply.

Thank you for the feedback, Jiri. Can you post a formal patch?

Lianbo.

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