[Crash-utility] question about phys_base

[HATAYAMA Daisuke]

From: Wen Congyang <wency at cn.fujitsu.com>
Subject: Re: question about phys_base
Date: Thu, 16 Feb 2012 09:16:28 +0800

> At 02/16/2012 12:17 AM, Dave Anderson Wrote:
>> 
>> 
>> ----- Original Message -----
>>> Hi, Dave
>>>
>>> I am implementing a new dump command in the qemu. The vmcore's
>>> format is elf(like kdump). And I try to provide phys_base in
>>> the PT_LOAD. But if the os uses the first vcpu do kdump, the
>>> value of phys_base is wrong.
>>>
>>> I find a function x86_64_virt_phys_base() in crash's code.
>>> Is it OK to call this function first? If the function
>>> successes, we do not calculate phys_base according to PT_LOAD.
>> 
>> I'm presuming that the qemu-generated ELF file is essentially
>> a "clone" of a kdump ELF file, and therefore the initialization
>> sequence would be:
>> 
>>  main()
>>   machdep_init(PRE_GDB)
>>    x86_64_init(PRE_GDB)
>>     x86_64_calc_phys_base()
>> 
>> where it should fall into this part:
>> 
>>         if ((vd = get_kdump_vmcore_data())) {
>>                 for (i = 0; i < vd->num_pt_load_segments; i++) {
>>                         phdr = vd->load64 + i;
>>                         if ((phdr->p_vaddr >= __START_KERNEL_map) &&
>>                             !(IS_VMALLOC_ADDR(phdr->p_vaddr))) {
>> 
>>                                 machdep->machspec->phys_base = phdr->p_paddr -
>>                                     (phdr->p_vaddr & ~(__START_KERNEL_map));
>> 
>>                                 if (CRASHDEBUG(1)) {
>>                                         fprintf(fp, "p_vaddr: %lx p_paddr: %lx -> ",
>>                                                 phdr->p_vaddr, phdr->p_paddr);
>>                                         fprintf(fp, "phys_base: %lx\n\n",
>>                                                 machdep->machspec->phys_base);
>>                                 }
>>                                 break;
>>                         }
>>                 }
>> 
>>                 return;
>>         } 
>> 
>> Question: will the qemu-generated ELF header contain a PT_LOAD segment that 
>> describes the mapped __START_KERNEL_map region?
>> 
>> If the __START_KERNEL_map PT_LOAD segment does *not* exist, then the code above 
>> would fall through to the "return", and I suppose that you could call 
>> x86_64_virt_phys_base() there instead.
>> 
>> If there *is* a __START_KERNEL_map PT_LOAD segment, are you saying that 
>> the calculation above would incorrectly calculate phys_base?
> 
> Because it is hard to calculate phys_base in qemu side. I try to do it like
> the function get_kernel_base() in qemu.c. But if the os uses the vcpu to do
> kdump, the phys_base is for the second kernel, not the first kernel. Another
> problem is that it is for linux, and we donot which the guest is.
> 

For the another problem, I don't know whether the way of checking the
type of running OS that is typically used, exists now, how about
letting users to specify the format through command-line? For example
--elf or --os=linux. Users who try to generate vmcore must know what
kind of OS is running, so I guess they can choose proper ones.

Of couse, if such way exists, it should be used.

>> 
>> Ideally, there would be some other "differentiator" between qemu-generated
>> and kdump-generated ELF headers -- while still being a KDUMP clone in all
>> other respects.  (Maybe an ELF NOTE?)  And then preferably, that differentiator
>> could be used to separate the code, i.e., something like:
> 
> The qemu-generated ELF headers may be the same as kdump-generated ELF headers.
> 
> Thanks
> Wen Congyang

kdump ELF vmcore has further VMCOREINFO.

$ readelf -n /media/pub3/vmcores/vmcore-2.6.35.14-106.fc14.x86_64-10000-threads

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

But diskdump/netdump ELF vmcore doesn't, so crash could possibly get
confused against this.

OTOH, I think qemu's CPU state information, CPUX86State structure, is
very useful debugging information. Because kvmdump format has the same
information, if this information is lost, this can be thouht of as a
kind of feature regression. So, how adding the information as new note
information?  Then, this can help crash to distinguish the vmcore from
the original kdump's.

Thanks.
HATAYAMA, Daisuke

>> 
>>        if (qemu_generated_ELF_kdump() {
>>                x86_64_virt_phys_base();
>>                return;
>>        }
>> 
>>        if ((vd = get_kdump_vmcore_data())) {
>>                 for (i = 0; i < vd->num_pt_load_segments; i++) {
>>                         phdr = vd->load64 + i;
>>                         if ((phdr->p_vaddr >= __START_KERNEL_map) &&
>>        ...
>>     
>> Would that be possible?
>> 
>> Dave
>> 
>> 
> 
>