Re: [Crash-utility] [PATH v4 1/2] arm64: fix kernel memory map handling for kaslr-enabled kernel
----- Original Message -----
> The VMCOREINFO is primarily there for the user-space kdump and
makedumpfile
> facilities. Crash does check it occasionally, but can't depend upon it,
> because there are too many other dumpfile formats.
That is the reason that I insist on minimizing the number of VMCOREINFO
parameters. Adding redundant ones can cause confusion in the future.
Again, there is the longstanding kdump_sub_header.phys_base interface
created by makedumpfile, in which the phys_base was a fundamental reason
for creating the kdump_sub_header to begin with. In fact, the "version 1"
of the kdump_sub_header contained just two fields, the phys_base and the
dump level.
> >
> > Using readmem() or not is a matter of implementation.
> > I think that we can use READMEM(), instead of readmem(), in
> > arm64_readme_kernel_symbol(), which is solely used, at least at the
> > moment, in arm64_calc_phys_offset().
>
> I'm sure I don't understand. Calling READMEM() as opposed to readmem()
> would require the virtual-to-physical address translation to be done
> on the "memstart_addr" symbol.
Right, but as I said,
- we've already calculated kaslr_offset with derive_kaslr_offset() called by
symtab_init(), which is prior to machdep_init(PRE_GDB).
- we can determine the *real(runtime)* virtual address of "memstart_addr" by
<vaddr> = <vaddr of memstart_addr in vmlinux> + kaslr_offset
- then we will identify the physical address by
<paddr> = <vaddr> - <kimage_voffset>
- so why cannot we call READMEM(pc->readmem) here(arm64_calc_phys_offset)
at the end of machdep_init(PRE_GDB)?
pc->readmem will be initialized definitely before any machdep_init(*).
See what I mean?
Logically, I don't see any breakage of existing APIs/assumptions.
(So I said, it is a matter of implementation.)
I understand, but I don't see the need to have a special case for arm64.
The makedumpfile/crash phys_base interface exists, so it should continue
to be used.
> > If so, what about, say, VA_BITS which will presumably be
needed as
> > VMCOREINFO later for makedumpfile but is calculated for now in
> > crash utility?
>
> Makedumpfile may require VA_BITS, but it's pretty straight forward in crash
> because we have the symbol values from the vmlinux file. That being
> the case, if it's available in VMCOREINFO, it could be used as an
> alternative for compressed kdumps or kdump ELF vmcores.
I know another example: VMCOREINFO("KERNELOFFSET"), which is actually
equal to "kaslr_offset".
It exists on x86, but is not utilized by crash util.
Right, its value is not used, but kaslr_init() does check for its existence.
> > Please don't take me wrong. I, as an author of kdump
for arm64, just want
> > to understand what parameters and why we want to have.
>
> Right, although it's going to be kind of play-as-we-go. The crash utility is
> going to require kdump-ELF and makedumpfile to offer the the things that
> it needs, but kdump-ELF/makedumpfile may have its own requirements to generate
> the things that the crash utility needs. As far as I can tell, at a minimum,
> VA_BITS, kimage_voffset and PHYS_BASE would be required.
I'm not quite sure, but do you, as a maintainer of crash, expect those
parameters to be also appended for crash?
AFAICT at the moment, kimage_voffset and PHYS_BASE would be required by crash,
i.e., whatever is required for virtual-to-physical address translation.
Dave