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

Yueyi Li liyueyi at live.com
Mon Mar 20 07:57:35 UTC 2017



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








-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-ARM64-patch-Auto-calculate-kimage_voffset.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20170320/df473d91/attachment.ksh>


More information about the Crash-utility mailing list