[Crash-utility] question about phys_base

[HATAYAMA Daisuke]

From: Wen Congyang <wency at cn.fujitsu.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Tue, 28 Feb 2012 13:10:38 +0800

> At 02/27/2012 10:10 PM, Dave Anderson Wrote:

>>> The guest is in the second kernel(vcpu > 1)
>>> ]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
>>>   LOAD           0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>   LOAD           0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>   LOAD           0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>   LOAD           0x0000000004017be0 0xffffffff81000000 0x0000000004000000
>> 
>> Again, it's not clear why there are multiple segments with the same
>> same virtual address, but I'm guessing that the one segment that starts 
>> at 0x0000000004000000 is associated with the second kernel, and the other
>> ones are for vcpus that ran in the first kernel?
>>  
>>> The guest is in the second kernel(vcpu = 1)
>>> [root at ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
>>>   LOAD           0x0000000004001e4c 0xffffffff81000000 0x0000000004000000
>>>
>>> I donot find differentiate qemu-genetated ELF headers from dump-generated ELF
>>> headers.
>> 
>> Kdump-generated vmcores cannot have multiple START_KERNEL_map segments.
>> But with dumps where (vpcu = 1), there could be confusion since it's not obvious
>> if START_KERNEL_map region belongs to the first or second kernel.  
>> 
>> That being the case, I don't see how this can be supported cleanly by the crash'
>> utility unless there is a NOTE, or some other obvious identifier, that absolutely
>> confirms that the dumpfile was qemu-generated.
> 
> The note information stored in qemu-generated core:
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   NOTE           0x000000000000edd0 0x0000000000000000 0x0000000000000000
>                  0x0000000000000590 0x0000000000000590         0
> 
> I think its format is the same as kdump's vmcore. Does kdump-generated core's
> virtaddr is always 0? If so, What about to set virt_addr to -1 in qemu-generated
> core?
> 

In general, such characteristic should not be used. You should prepare
a solid interface. Even if using them, it should be limited to as
workaround to avoid some issue.

Why not use qemu's CPU state? Include it as note information with good
name, and we can use it to distinguish which. Like:

$ readelf -n vmcore

Notes at offset 0x000001c8 with length 0x00000838:
  Owner         Data size       Description
  CORE          0x00000150      NT_PRSTATUS (prstatus structure)
  CORE          0x00000150      NT_PRSTATUS (prstatus structure)
  QEMU          0x00000557      Unknown note type: (0x00000000)

Or QEMUCPUState is better?

Thanks.
HATAYAMA, Daisuke