[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 17:04:30 +0800

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

For QEMUCPUState, I mean CPUState type information in qemu. It has
machine state information and is very useful for debugging. QEMU
maintainer says it's necessary and I thought adding this note is
natural story.

If adding this in dumpfile, we can at least do the same thing as
kvmdump to calculate phys_base.

To make this note as meaningful as we can say ``gdb works well'',
command to display CPUState is needed. Just like registers command.

(gdb) info registers
rax            0x10     16
rbx            0x63     99
rcx            0x1194   4500
rdx            0x0      0
rsi            0x0      0
rdi            0x63     99
rbp            0xffff88012187be48       0xffff88012187be48
rsp            0xffff88012187be48       0xffff88012187be48
r8             0x0      0
r9             0xffffffffffffffff       -1
r10            0xffff88013fc06000       -131936030793728

These values can be referenced with notation $rax, so it would be
happier if able to do the same thing for QEMUCPUState, but not
definite if too complicated to implement.

That's all for idea I have for gdb now.

Thanks.
HATAYAMA, Daisuke