From: Dave Anderson <anderson@xxxxxxxxxx> Subject: Re: question about phys_base Date: Thu, 16 Feb 2012 10:39:04 -0500 (EST) > > > ----- Original Message ----- >> From: Wen Congyang <wency@xxxxxxxxxxxxxx> >> 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 > Thanks. I've just noticed. I've not read the thread yet. That's better. Thanks. HATAYAMA, Daisuke -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility