[Crash-utility] question about phys_base

[Dave Anderson]

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

Right -- that would be a good idea.  In fact I thought I read that
someone on the qemu-devel list had suggested that Wen do just that.

Dave  

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