Re: [Crash-utility] [ARM64][patch v6] Auto calculate kimage_voffset

On 2017/3/18 4:27, Dave Anderson wrote: > > ----- Original Message ----- >> On 2017/3/17 22:25, Dave Anderson wrote: >>> ----- Original Message ----- >>>> However, that is why I am interested in your live system initialization >>>> of kimage_voffset -- for live system access using /dev/mem, /proc/kcore, >>>> or an older version of the /dev/crash driver that did not have the >>>> ioctl() >>>> to read kimage_voffset. But, in order to do that, >>>> arm64_calc_kimage_voffset() >>>> needs to be able to handle all /proc/iomem cases to correctly calculate >>>> PHYS_OFFSET. >>> Or better stated, your arm64_calc_kimage_voffset() needs to be able to >>> handle all >>> /proc/iomem cases to correctly calculate kimage_voffset. Because on the >>> 4.8 >>> kernel, it does not work. >> Dave, >> >> Sorry for my misunderstanding of PHYS_OFFSET, actually kimage_voffset >> is the offset between kernel virtual address and physical address. So, >> to calculate it need find out which physical address is mapping to >> VA_START, not PHYS_OFFSET. >> >> Please check patch v5, it should be OK for live system. >> >> Thanks, >> Yueyi > > Yueyi, > > Yes, thanks, this patch does select the correct "offset" for > use by your calculation. On both the 4.8 and 4.10 kernels, > the System RAM segment at 0x4000200000 is selected. > > However, I wonder if it would be simpler to just select the > System RAM segment that *contains* the "Kernel code" segment, > which would follow it in /proc/iomem: > > 4.8 kernel: > > 4000000000-40001fffff : System RAM > 4000200000-43fa59ffff : System RAM > 4000280000-4000c7ffff : Kernel code > 4000d90000-400166ffff : Kernel data > 43fa5a0000-43fa9dffff : System RAM > 43fa9e0000-43ff99ffff : System RAM > 43ff9a0000-43ff9affff : System RAM > 43ff9b0000-43ff9bffff : System RAM > 43ff9c0000-43ff9effff : System RAM > 43ff9f0000-43ffffffff : System RAM > > 4.10 kernel: > > 4000000000-40001fffff : reserved > 4000200000-4001ffffff : System RAM > 4000280000-4000ccffff : Kernel code > 4000e00000-40016effff : Kernel data > 40023b0000-4ff733ffff : System RAM > 4ff7340000-4ff77cffff : reserved > 4ff77d0000-4ff792ffff : System RAM > 4ff7930000-4ff7e7ffff : reserved > 4ff7e80000-4ff7e8ffff : System RAM > 4ff7e90000-4ff7efffff : reserved > 4ff7f10000-4ff800ffff : reserved > 4ff8010000-4fffffffff : System RAM > > In other words, just walk through the /proc/iomem entries, saving > the System RAM start address as you go. Then when "Kernel code" is > found, use the last RAM start address. > > And a couple other things... > > For backwards compatibility (i.e., kernels without kimage_voffset), > the call from arm64_init() should be conditional like this: > > if (machdep->flags & NEW_VMEMMAP) > arm64_calc_kimage_voffset(); > > And for live systems without /dev/crash, it wouldn't be necessary to > add "--kaslr=0" to the command line if arm64_calc_kimage_voffset() started > something like this: > > static void > arm64_calc_kimage_voffset(void) > { > struct machine_specific *ms = machdep->machspec; > ulong offset; > > if (ms->kimage_voffset) /* vmcoreinfo, --machdep override, or > ioctl */ > return; > > if (DUMPFILE()) { > if (!(kt->flags2 & KASLR) || !(kt->flags & RELOC_SET)) > return; > } > ... > > What do you think? > > Thanks, > Dave > > -- > Crash-utility mailing list > Crash-utility(a)redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility Agreed, I have made change as your recommendation. For NEW_VMEMMAP, always calculate kimage_voffset if it not be given. Thanks, Yueyi