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

[Nicholas Piggin]

Oliver's on May 21, 2019 11:20 am:
> 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.

I was specifically talking about the "preserve memory across reboots"
facility, it sounded like you said the minimum was not enough.

I think API specifics are important -- there is no question the
functionality can't be achieved with the proposed API. I just had
some different opinions about it.

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

No but that's not a reson not to implement minimal APIs with clean
separation of functionality. I don't see the controversy about a
simple "preserve memory ranges" API.

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

How?

Thanks,
Nick