[Crash-utility] question about phys_base

[Dave Anderson]

----- Original Message -----
> > 
> > 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.

> 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

Why are there multiple segments describing the same virtual/physical region?
Is there one START_KERNEL_map segment for each vcpu?  Are their FileSiz/MemSiz
values all the same?

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

Dave