[Crash-utility] question about phys_base

[Wen Congyang]

At 02/24/2012 09:37 PM, Dave Anderson Wrote:
> 
> 
> ----- Original Message -----
>> At 02/17/2012 10:20 PM, Dave Anderson Wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> At 02/17/2012 12:30 AM, Dave Anderson Wrote:
>>>
>>>>>> Yes. Even if the guest is linux, it is still impossible to do it.  Because
>>>>>> the guest maybe in the second kernel.
>>>>>>
>>>>>> qemu-dump walks all guest's page table and collect virtual address and
>>>>>> physical address mapping. If the page is not used by guest, the virtual is set
>>>>>> to 0.  I create PT_LOAD according to such mapping. So if the guest linux,
>>>>>> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
>>>>>> But the information stored in PT_LOAD maybe for the second. If crash
>>>>>> uses it, crash will see the second kernel, not the first kernel.
>>>>>
>>>>> Just to be clear -- what do you mean by the "second" kernel?  Do you
>>>>> mean that a guest kernel crashed guest, and did a kdump operation,
>>>>> and that second kdump kernel failed somehow, and now you're trying
>>>>> to do a "virsh dump" on the kdump kernel?
>>>>
>>>> Yes, the second kernel means kdump kernel. If kdump failed, the user can
>>>> use it to dump the guest's memory.
>>>
>>> OK, so will your code present two different "types" of ELF headers?
>>
>> I donot understand what do you want to say.
>> Do you mean there is two ELF headers in qemu-generated vmcore?
> 
> No.  What I want to understand is how x86_64_calc_phys_base() will
> be able to confidently recognize that an ELF file was qemu-generated,
> so that it can then do the right thing.
> 
> And from your description, it sounds like there will be different PT_LOAD
> descriptors based upon whether it's the first or second kernel.  And
> the difference between the two would be based upon which (if any) of the
> following statements are true:
> 
>  (1) first kernel -- contains a valid __START_KERNEL_map PT_LOAD segment
>  (2) first kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment 
>  (3) second kernel -- contains an invalid (first kernel) __START_KERNEL_map PT_LOAD segment 
>  (4) second kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment
>  (5) ???

The guest is in first kernel:
# readelf /tmp/vm2.save -l| grep 0xffffffff8
  LOAD           0x00000000010226b8 0xffffffff81000000 0x0000000001000000
  LOAD           0x00000000010226b8 0xffffffff81000000 0x0000000001000000
  LOAD           0x00000000010226b8 0xffffffff81000000 0x0000000001000000
  LOAD           0x00000000010226b8 0xffffffff81000000 0x0000000001000000

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

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.

Thanks
Wen Congyang
> 
> What will differentiate qemu-generated ELF headers from kdump-generated ELF
> headers?
> 
> Dave
>