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

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:

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

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

----- Original Message ----- > From: Wen Congyang <wency(a)cn.fujitsu.com&gt; > 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