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

Dave Anderson anderson at redhat.com
Mon Mar 20 15:25:54 UTC 2017



----- Original Message -----
> 
> 
> 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 at 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
> 

Ok, this looks good.

One minor thing --- I removed the DISKDUMP_DUMPFILE() check from arm64_calc_kimage_voffset(),
because if the compressed dumpfile does not contain the kimage_voffset value in its 
VMCOREINFO, then I want the generic error message to be displayed.

Queued for crash-7.1.9:

  https://github.com/crash-utility/crash/commit/0cb149ba43e8d455185745e38b75cc1e0655a0c0
 
Thanks,
  Dave


  




More information about the Crash-utility mailing list