----- Original Message -----
>
>
> Hi Dave,
>
>
>
>
> In my develop enviroment, kaslr offset will be stored in SoC on-chip memory
> for debuging, but crash utility is not work if i only set kaslr offset by
> command '--kaslr XXX', it also need correct kimage_voffset.
>
> error message without the patch:
>
> VA_BITS: 39
> using 40000000 as phys_offset
> kimage_voffset: 0
> phys_offset: 40000000
> .....cut....
> <readmem: ffffff9381e074a0, KVADDR, "cpu_possible_mask", 8, (FOE),
> 7fffce0dfa48>
> <read_ramdump: addr: ffffff9381e074a0 paddr: 13b9e074a0 cnt: 8>
> read_ramdump: READ_ERROR: offset not found for paddr: 13b9e074a0
> crash: read error: kernel virtual address: ffffff9381e074a0 type:
> "cpu_possible_mask"
>
> This patch add a function to auto calculate kimage_voffset by kaslr offset.
> Please review it.
>
> Thanks,
> Yueyi Li
Hello Yueyi,
I have a few questions about this patch.
First, can you clarify the kernel version and the dumpfile type that
you are trying to address?
I understand the confusion, given that arm64 kdump/KASLR support is still being
debated upstream. Eventually, arm64 kdump-generated dumpfiles will have
"NUMBER(kimage_voffset)" and "NUMBER(PHYS_OFFSET)" VMCOREINFO entries, which
will simplify things significantly (and you can see that the crash utility
already has support for them in advance).
It seems that this patch would only be applicable when looking at an ELF
dumpfile, given that your arch_calc_kimage_voffset() function calls
arm_kdump_phys_base() -- which only applies if you are looking at an
ELF dumpfile:
+static void
+arm64_calc_kimage_voffset(void)
+{
+ struct machine_specific *ms = machdep->machspec;
+ ulong kimage_offset;
+ ulong phys_offset;
+ struct syment *sp;
+
+ if (machdep->flags & KIMG_VOFFSET) /* --machdep override */
+ return;
+
+ if ((kt->flags2 & KASLR) && (kt->flags & RELOC_SET)){
+ arm_kdump_phys_base(&phys_offset);
+ ms->kimage_voffset = ms->vmalloc_start_addr + (kt->relocate * -1) - phys_offset;
+ }
+
+}
Is that correct? And if so, why not call arm64_kdump_phys_base() instead?
Because I see in your "error message without the patch" above, the phys_base
seems to have been calculated correctly to be 40000000, so it looks like the
call from arm64_calc_phys_offset() to arm64_kdump_phys_base() must have worked.
(since arm64_kdump_phys_base() ultimately calls arm_kdump_phys_base() if nothing
else works)
So what would happen if you called arm64_calc_phys_offset() *before* your new
function? Wouldn't it correctly determine phys_offset? And then there would
be no need for you to call it in your new function:
@@ -324,6 +325,9 @@ arm64_init(int when)
machdep->init_kernel_pgd = arm64_init_kernel_pgd;
/* use machdep parameters */
+ arm64_calc_kimage_voffset();
+
+ /* use machdep parameters */
arm64_calc_phys_offset();
In addition, arm64_calc_phys_offset() also tries to determine the phys_offset value
for compressed kdump dumpfiles and live systems. If the dumpfile has been
compressed (by the makedumpfile facility), or if you are running on a live system,
then your patch would fail to determine phys_offset. But if you were to call
arm64_calc_phys_offset() instead, it would call diskdump_phys_base() for compressed
dumpfiles, or try to determine the phys_offset value from /proc/iomem on live
systems.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
