On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote: > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote: > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote: > > [...] > > > > > (This is the reason that I don't think we need a VMCOREINFO for > > > > CONFIG_RANDOMIZE_BASE.) > > > > > > Well, as long as there's a way to avoid that unnecessary/confusing > > > warning message for non-KASLR new-vmemmap kernels. > > > > > > I also wonder whether makedumpfile could use it? > > > > -> Pratyush? > > Since second kernel's initrd cannot include a large file like VMLINUX, so > makedumpfile should also work without passing '-x vmlinux'. Therefore, > makedumpfile will need some minimal symbol's values to be passed in vmcore. I understand. (but I wonder why makedumpfile doesn't utilize System.map nor .config.) > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore. No, as I said in the discussions, I don't think that we need CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value from /proc/vmcore. > Following numbers in vmcore [1] is helping me out in implementing __pa() and > __va() for all page table sizes and levels. > > VMCOREINFO_NUMBER(pgtable_levels); > VMCOREINFO_NUMBER(va_bits); > VMCOREINFO_NUMBER(page_shift); Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift. As well, pgtable_levels can be determined by va_bits and PAGESIZE. See arch/arm64/Kconfig. > VMCOREINFO_NUMBER(phys_offset); > VMCOREINFO_NUMBER(config_kasan); Let me ask some questions. * What kind of data in vmcore and how does makedumpfile access without vmlinux nor System.map? * Why do you need CONFIG_KASAN? Thanks, -Takahiro AKASHI > VMCOREINFO_NUMBER(kimage_voffset); > > ~Pratyush > > [1] > https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275 > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility -- Thanks, -Takahiro AKASHI -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
