[PATCH v4 5/5] RISC-V: Add crash kernel support

[Rob Herring]

+Ard

On Tue, Jun 15, 2021 at 5:29 PM Nick Kossifidis <mick at ics.forth.gr> wrote:
>
> Στις 2021-06-15 22:21, Rob Herring έγραψε:
> > On Tue, Jun 15, 2021 at 12:48 PM Geert Uytterhoeven
> > <geert at linux-m68k.org> wrote:
> >>
> >> Hi Nick,
> >>
> >> On Tue, Jun 15, 2021 at 8:29 PM Nick Kossifidis <mick at ics.forth.gr>
> >> wrote:
> >> > Στις 2021-06-15 16:19, Geert Uytterhoeven έγραψε:
> >> > > This does not match
> >> > > https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml#L77:
> >> > >
> >> > >     $ref: types.yaml#/definitions/uint64-array
> >> > >     maxItems: 2
> >> > >     description:
> >> > >       This property (currently used only on arm64) holds the memory
> >> > > range,
> >> > >       the address and the size, of the elf core header which mainly
> >> > > describes
> >> > >       the panicked kernel\'s memory layout as PT_LOAD segments of elf
> >> > > format.
> >> > >
> >> > > Hence "linux,elfcorehdr" should be a property of the /chosen node,
> >> > > instead of a memory node with a compatible value of "linux,elfcorehdr".
> >> > >
> >> >
> >> > That's a binding for a property on the /chosen node, that as the text
> >> > says it's defined for arm64 only and the code that handled it was also
> >>
> >> That doesn't mean it must not be used on other architectures ;-)
> >> Arm64 was just the first one to use it...
> >
> > It is used on arm64 because memory is often passed by UEFI tables and
> > not with /memory node. As riscv is also supporting EFI, I'd think they
> > would do the same.
> >
>
> We've had this discussion before, riscv uses /memory for now and even if
> we switched to getting memory from ACPI/UEFI tables, the elf core header
> is passed from the crashed kernel to the kdump kernel, it has nothing to
> do with UEFI since the bootloader is the kernel itself. Am I missing
> something ?

I believe if we originally booted using UEFI tables, then those are
passed the kdump kernel as well. The original DT may have had a
/memory node, but it's possible it didn't match what was in the UEFI
tables. So using the DT /memory nodes for kdump could give surprising
results. I think reserved regions also come from UEFI. Ard can
probably comment better.

Rob