[Crash-utility] question about phys_base

[Wen Congyang]

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.

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