At 02/24/2012 09:37 PM, Dave Anderson Wrote: > > > ----- Original Message ----- >> At 02/17/2012 10:20 PM, Dave Anderson Wrote: >>> >>> >>> ----- Original Message ----- >>>> At 02/17/2012 12:30 AM, Dave Anderson Wrote: >>> >>>>>> Yes. Even if the guest is linux, it is still impossible to do it. Because >>>>>> the guest maybe in the second kernel. >>>>>> >>>>>> qemu-dump walks all guest's page table and collect virtual address and >>>>>> physical address mapping. If the page is not used by guest, the virtual is set >>>>>> to 0. I create PT_LOAD according to such mapping. So if the guest linux, >>>>>> there may be a PT_LOAD segment that describes __START_KERNEL_map region. >>>>>> But the information stored in PT_LOAD maybe for the second. If crash >>>>>> uses it, crash will see the second kernel, not the first kernel. >>>>> >>>>> Just to be clear -- what do you mean by the "second" kernel? Do you >>>>> mean that a guest kernel crashed guest, and did a kdump operation, >>>>> and that second kdump kernel failed somehow, and now you're trying >>>>> to do a "virsh dump" on the kdump kernel? >>>> >>>> Yes, the second kernel means kdump kernel. If kdump failed, the user can >>>> use it to dump the guest's memory. >>> >>> OK, so will your code present two different "types" of ELF headers? >> >> I donot understand what do you want to say. >> Do you mean there is two ELF headers in qemu-generated vmcore? > > No. What I want to understand is how x86_64_calc_phys_base() will > be able to confidently recognize that an ELF file was qemu-generated, > so that it can then do the right thing. > > And from your description, it sounds like there will be different PT_LOAD > descriptors based upon whether it's the first or second kernel. And > the difference between the two would be based upon which (if any) of the > following statements are true: > > (1) first kernel -- contains a valid __START_KERNEL_map PT_LOAD segment > (2) first kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment > (3) second kernel -- contains an invalid (first kernel) __START_KERNEL_map PT_LOAD segment > (4) second kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment > (5) ??? The guest is in first kernel: # readelf /tmp/vm2.save -l| grep 0xffffffff8 LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000 LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000 LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000 LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000 The guest is in the second kernel(vcpu > 1) ]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8 LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000 LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000 LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000 LOAD 0x0000000004017be0 0xffffffff81000000 0x0000000004000000 The guest is in the second kernel(vcpu = 1) [root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8 LOAD 0x0000000004001e4c 0xffffffff81000000 0x0000000004000000 I donot find differentiate qemu-genetated ELF headers from dump-generated ELF headers. Thanks Wen Congyang > > What will differentiate qemu-generated ELF headers from kdump-generated ELF > headers? > > Dave > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility