----- 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
