----- 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