----- Original Message ----- > Hi Dave, > > On 11/01/16 at 10:13am, Dave Anderson wrote: > > > > > > > > But we have this in mainline which also introduced the VMCOREINFO > > > > numbers, can you send a patch to revert them? > > > > > > OK, will do. > > > > > > However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is > > > still needed. I checked code, seems no better way to avoid. I am not > > > sure how many people are really using "-e" option to exclude unused > > > vmemmap pages. > > > > > > Maybe just leave it as is, and fix it when people complain? > > > > Speaking of complaints, is there any chance you can make the > > x86_64 "phys_base" value available? The VMCOREINFO_SYMBOL(phys_base) > > is useless since its contents are needed in order to access the > > symbol address. > > Yeah, the current exporting of virt addr of phys_base is really useless > for x86_64. While I saw you have got phys_base from kdump-ed vmcore elf > program header since kexec-tools has created that pt_load for kernel text > region. > > machdep->machspec->phys_base = phdr->p_paddr - (phdr->p_vaddr & > ~(__START_KERNEL_map)); > > Do you still want the value of phys_base? If yes, I can change it to > export the real value of phys_base, not &phys_base. > > In fact, exporting &phys_base was done in 2008, makedumpfile has taken > the similar way you use in crash to get value of phys_base. Means it has > been ignored very earlier. You could be the first person to complain > about it. No, this is not the first time it's been brought up. Anyway, yes, it would be preferable if it were readily available in vmcoreinfo rather than depending upon the PT_LOAD semantics. Thanks, Dave
