[Crash-utility] [PATH v4 1/2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Dave Anderson]

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