Magnus Damm wrote: > 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
I don't mean to dumb-down the discussion here, but... With respect to the crash utility, for all identity-mapped kernel virtual addresses (symbols) in the vmlinux file, we need a way to find them in the vmcore. Traditionally, the virtual address could simply have the PAGE_OFFSET value stripped, leaving the physical address. And then the PT_LOAD segments in the vmcore file could be searched for the segment containing the target physical address. In that case, there's no need for the p_vaddr field in the vmcore. For relocatable x86_64 kernels, and for ia64 kernels which are relocatable by design, the stripping of the PAGE_OFFSET value won't suffice by itself -- the resultant value needs to be offset by the physical base address. (BTW, x86 still "just works", relocatable or not) There's nothing in the vmlinux file that indicates where the physical base address is, so the use of the special kernel text/static-data segments in the kdump vmcore, __START_KERNEL_map for x86_64, and the mapped region 5 KERNEL_START segment for ia64, currently give the physical base address in the relevant kdump p_paddr field -- directly in ia64, and by simple calculation in the case of x86_64. In any case, *something* is needed to give the crash utility the physical base address used for identity-mapped kernel virtual addresses in those circumstances where it's not zero. Of course, as you state, gdb is whole different story... Dave _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
