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

[Nicholas Piggin]

Hari Bathini's on June 4, 2019 5:08 pm:
> 
> On 03/06/19 11:52 PM, Hari Bathini wrote:
> [...]
>>>> So you retrieve you kernel metadata pointer that's in dest memory,
>>>> and that contains all your saved ranges and other metadata.
>>> During MPIPL, hostboot takes care of  moving data from source to destination memory.
>>> Hostboot point of view its just memory preserving (copying memory from source to
>>> destination). It doesn't differentiate whether its kernel memory -OR- OPAL memory.
>>> Once it completes it boots OPAL and passes result table to OPAL. This result table contains both OPAL and kernel entries. We have to pass this information to kernel. Also kernel needs a way
>>> to differentiate between OPAL and kernel entries.
>>>
>>>
>>> So here is my new interface proposal. Does this looks ok?
>>>
>>> Registration :
>>>   opal_fadump_manage(u8 cmd, u64 src, u64 dest,  u64 size)
>>>       cmd :  0x01 -> OPAL_FADUMP_REGISTER , kernel should pass all 3 parameters
>>>                  0x02 -> OPAL_FADUMP_UNREGISTER, kernel should pass src and dest parameter
>>>                               if src = dest = 0, then UNREGISTER all kernel entries
>>>                  0x03 -> OPAL_FADUMP_INVALIDATE, No parameter is required.
>>>
>>>     - OPAL will add new entry to MDST/MDST table
>>>     - If system crashes before kernel adds all entry, we will have partial kernel dump
>>>     - Kernel should handle partial dumps
>>>
>>>     - Kernel has to maintain its metadata. If in future, multiple driver wants different dumps
>>>       they have to go through same interface (CONFIG_FADUMP).
>>>
>> The interface looks nice but is it not worth having a field that differentiates different callers
>>
>> of opal_fadump/mpipl_manage() from kernel to avoid enforcing a single owner to this call in
>>
>> kernel that has to keep a tab of all callers to this function with metadata..
> 
> 
> Nick, your thoughts?

I think the convention should be just a single caller should manage
the MPIPL. Or they coordinate and synchronize outside of the MPIPL
calls (e.g., with shared data structures).

Thanks,
Nick