Hi everyone,
I'm wondering if we are exporting more information than we actually need
in our vmcore files. I think it would be nice to remove hardcoded kernel
constants in the kexec-tools package if possible.
Here is the program header output of readelf -a on a x86_64 vmcore from
2.6.19-rc5 (with saved_max_pfn fix):
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000158 0x0000000000000000 0x0000000000000000
0x00000000000002c8 0x00000000000002c8 0
LOAD 0x0000000000000420 0xffffffff80200000 0x0000000000200000 <- K
0x00000000002a2000 0x00000000002a2000 RWE 0
LOAD 0x00000000002a2420 0xffff810000000000 0x0000000000000000 <- R
0x00000000000a0000 0x00000000000a0000 RWE 0
LOAD 0x0000000000342420 0xffff810000100000 0x0000000000100000 <- R
0x0000000001f00000 0x0000000001f00000 RWE 0
LOAD 0x0000000002242420 0xffff810006000000 0x0000000006000000 <- R
0x00000000397f0000 0x00000000397f0000 RWE 0
The PT_LOAD program headers above are marked with K for kernel and R for
physical RAM. The plan is that the kernel segment should be replaced
with a hypervisor segment under Xen, but that is not what this email is
about.
To be able to use gdb on a vmcore file we need the PT_LOAD segment for
the kernel - marked with K above. This is true for relocatable kernels
and crash too.
For gdb we need VirtAddr and maybe PhysAddr too. It should be possible
for kexec-tools to determine VirtAddr from the running kernel
using /proc/kcore or /proc/kallsyms. PhysAddr can be determined
from /proc/iomem or maybe /proc/config.gz as fallback.
Say we cannot determine one of VirtAddr, PhysAddr or MemSiz for the
kernel segment. In that case I think we should skip creating a PT_LOAD
program header for the kernel. That should only be the case on old
kernels, and in that case the utility used to analyze the vmcore can
fallback on getting these values from vmlinux. This means that gdb will
fail but maybe that is ok on old kernels?
The PT_LOAD program headers for RAM are easy when it comes to PhysAddr
and MemSiz. For VirtAddr it seems more complicated today, PAGE_OFFSET
and MAXMEM are both hardcoded in crashdump-x86.h for i386, and
PAGE_OFFSET in crashdump-x86_64.h for x86_64. Do we really need VirtAddr
for RAM program headers?
If we need VirtAddr for RAM - which utility is relying that then and
does it have to? Can't we just set VirtAddr to -1 and be done with it?
We don't have virtual address space for all physical RAM on i386 today
anyway, and -1 is how we handle HIGHMEM on i386 already. Using a
hardcoded PAGE_OFFSET on x86 does not work well with the VMSPLIT kernel
config options, so I'd like to get rid of it all together if possible.
If we can agree on trying not to hardcode things then I believe that we
can remove the following from crashdump-x86.h and crashdump-x86_64.h:
PAGE_OFFSET, MAXMEM and __VMALLOC_RESERVE. Maybe __START_KERNEL_map and
KERNEL_TEXT_SIZE. For x86_64 __pa() can be removed if I'm right, on i386
we still need it unless we can come up with a better way to implement
get_crash_notes().
How does that sound? I think that hardcoding as little as possible
should lead to a more stable and maintainable piece of software.
/ magnus
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
