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

[Oliver]

On Mon, May 20, 2019 at 5:16 PM Nicholas Piggin <npiggin at gmail.com> wrote:
>
> 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.

I didn't suggest adding one. Everything above can be implemented with
the <src, dst, len> API above and a single additional OPAL call to set
the post MPIPL entry point. You can call that a different facility if
you really want, but I don't think it matters. The point of this
series is to implement fadump, so I'd like us to spend a bit of time
thinking about what fadump is supposed to do rather than just arguing
about API specifics.

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

Did you have some other use for MPIPL in mind? My thinking is that
attempting to design a generic API with only a single consumer results
in the assumptions of that user being baked into the API anyway.

> Thanks,
> Nick