[Skiboot] [PATCH v4 13/18] fadump: Add OPAL API to register for fadump

[Vasant Hegde]

On 08/07/2018 01:15 PM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
>> This patch adds new API for fadump.
>>    int64_t opal_fadump_manage(uint64_t cmd, void *data, uint64_t dsize)
>>
>>    cmd : 0x01 -> Register for fadump
>>          0x02 -> Unregister fadump
>> 	0x03 -> Invalidate existing dump
>>
>>    data : For cmd = 0x01, data contains payload section reservation details
>>           (uses fadump structure format to send data).
>>           For other cmd values, data will be NULL.
>>    dsize: Size of data
>>
>> Return values:
>>    OPAL_SUCCESS   : Operation success
>>    OPAL_PARAMETER : Payload passed invalid data
>>    OPAL_RESOURCE  : Ran out of MDST, MDDT table size
>>    OPAL_PERMISSION: Already registered
>>    OPAL_HARDWARE  : Fadump not supported
> 
> I'm thinking that the existing OPAL_(UN)REGISTER_DUMP_REGION calls could
> be adequate here?

Unfortunately OPAL_(UN)REGISTER_DUMP_REGION is not sufficient. In case of current
FSP SYSDUMP, kernel just passes memory to be captured. OPAL takes care of TCE 
mapping.

But in case of MPIPL, we want kernel to reserve memory for kernel dump and pass 
that detail
to OPAL.

> 
> Even in the case where the kernel doesn't know anything about the new
> dump infrastructure, if we passed something back via the OPAL_DUMP_READ
> interface that we use on FSP systems today, we'd have a net gain in
> functionality without any kernel (or userspace) changes. Or am I missing
> something?

In case of SYSDUMP, we want kernel to allocate memory, pass detail to OPAL. OPAL 
does TCE
mapping and gets actual dump from FSP.

But in case of MPIPL, flow is different. Here during first boot (before crash) 
we populate
MDST  and MDDT table inside HDAT/SPIRAH structure with details of source and 
destination
memory. During crash boot (second boot) Hostboot will take care of moving memory 
content.
By the time we boot OPAL we already have memory content in destination memory. 
Kernel
will use these details to generate vmcore and opal core.

One thing we can consider is exporting OPAL dump via sysfs (similar to the way 
we export
raw HDAT content). So that even if kernel doesn't know anything about MPIPL we 
can still retrieve OPAL dump. I will add that support once this patchset is merged.

-Vasant