Re: [Crash-utility] question about phys_base

At 02/28/2012 02:30 PM, HATAYAMA Daisuke Wrote: > From: Wen Congyang <wency(a)cn.fujitsu.com&gt; > Subject: Re: [Crash-utility] question about phys_base > Date: Tue, 28 Feb 2012 13:10:38 +0800 > >> At 02/27/2012 10:10 PM, Dave Anderson Wrote: > >>>> 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 >>> >>> Again, it's not clear why there are multiple segments with the same >>> same virtual address, but I'm guessing that the one segment that starts >>> at 0x0000000004000000 is associated with the second kernel, and the other >>> ones are for vcpus that ran in the first kernel? >>> >>>> 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. >>> >>> Kdump-generated vmcores cannot have multiple START_KERNEL_map segments. >>> But with dumps where (vpcu = 1), there could be confusion since it's not obvious >>> if START_KERNEL_map region belongs to the first or second kernel. >>> >>> That being the case, I don't see how this can be supported cleanly by the crash' >>> utility unless there is a NOTE, or some other obvious identifier, that absolutely >>> confirms that the dumpfile was qemu-generated. >> >> The note information stored in qemu-generated core: >> Program Headers: >> Type Offset VirtAddr PhysAddr >> FileSiz MemSiz Flags Align >> NOTE 0x000000000000edd0 0x0000000000000000 0x0000000000000000 >> 0x0000000000000590 0x0000000000000590 0 >> >> I think its format is the same as kdump's vmcore. Does kdump-generated core's >> virtaddr is always 0? If so, What about to set virt_addr to -1 in qemu-generated >> core? >> > > In general, such characteristic should not be used. You should prepare > a solid interface. Even if using them, it should be limited to as > workaround to avoid some issue. > > Why not use qemu's CPU state? Include it as note information with good > name, and we can use it to distinguish which. Like: > > $ readelf -n vmcore > > Notes at offset 0x000001c8 with length 0x00000838: > Owner Data size Description > CORE 0x00000150 NT_PRSTATUS (prstatus structure) > CORE 0x00000150 NT_PRSTATUS (prstatus structure) > QEMU 0x00000557 Unknown note type: (0x00000000) > > Or QEMUCPUState is better? Good idea. I will try it, and hope gdb can also work.