[Crash-utility] question about phys_base

[Wen Congyang]

At 02/28/2012 04:52 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency at cn.fujitsu.com>
> Subject: Re: [Crash-utility] question about phys_base
> Date: Tue, 28 Feb 2012 16:36:59 +0800
> 
>> At 02/28/2012 02:30 PM, HATAYAMA Daisuke Wrote:
>>> 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?
>>
>> Good idea. I will try it, and hope gdb can also work.
>>
> 
> Tools basically ignore unknown notes. Looking into gdb, it appears to
> ignore unknown information.
> 
> static bfd_boolean
> elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
> {
>   const struct elf_backend_data *bed = get_elf_backend_data (abfd);
> 
>   switch (note->type)
>     {
>     default:
>       return TRUE;
> <cut>
> 
> You might need to add new command to output contents of new note if
> it's necessary.

My goal is:
1. gdb uses NT_PRSTATUS, and can work well
2. crash uses unknown notes, and can get phys_base from it.

Another question:

What is QEMUCPUState? I donot find its definition?
What note->type shoule be for "QEMU"? If we choose an unused value, the
value may be used in the future.

Thanks
Wen Congyang

> 
> Thanks.
> HATAYAMA, Daisuke
> 
>