[Skiboot] [PATCH v7 18/22] fadump: Add documentation

[Nicholas Piggin]

Oliver's on May 20, 2019 4:20 pm:
> On Mon, May 20, 2019 at 12:30 PM Nicholas Piggin <npiggin at gmail.com> wrote:
>>
>> I'm still pretty set on no structure and no metadata (except one tag
>> that has no predefined semantics to the MPIPL layer).
>>
>> That's the minimum necessary and sufficient for a "preserve memory
>> across reboot" facility to support Linux crash dumps, right?
> 
> I think we can (and probably need to) do better than the minimum. For
> the current design the "good" path is something like:
> 
> Old kernel does a bad -> MPIPL request -> *magic occurs* -> hostboot
> -> skiboot -> petitboot -> ???
> 
> I'm wondering what we can safely do once we hit the final step. As far
> as I can tell the intention is to boot into the same kernel that we
> crashed from so that it can run makedumpsterfire to produce a
> crashdump, invalidate the dump, and continue to boot into a
> functioning OS. However I don't see how we'd actually guarantee that
> actually happens. I realise that it's *probably* going to work most of
> the time since we'll probably be running the same kernel that's the
> default boot option, but surely we can come up with something that's
> less jank.
> 
> For contrast the kdump approach allows the crashing kernel to specify
> what the crash environment is going to look like. If I were an OS
> vendor I'd say that's a pretty compelling reason to use kdump instead
> of this. If the main benifit of fadump is that we can reliably reset
> and reinitialise hardware devices then maybe we should look at trying
> to use MPIPL as an alternative kdump entry path. Rather than having
> skiboot load petitboot from flash, we could have skiboot enter the
> preloaded crash kernel and go from there.

That'd be a different facility. We don't want a kitchen sink
"do a fadump" API.

The memory preserving IPL APIs should just specify what memory to
preserve (and a way to retrieve it). That's it.

Thanks,
Nick