Re: [Crash-utility] question about phys_base

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?

Thanks. HATAYAMA, Daisuke