[Skiboot] [PATCH v8 12/24] MPIPL: Add OPAL API to register for dump

[Vasant Hegde]

On 06/28/2019 07:09 AM, Nicholas Piggin wrote:
> Vasant Hegde's on June 17, 2019 3:10 am:
>> This patch add new API to register for dump.
>>    u64 opal_mpipl_update(u8 ops, u64 src, u64 dest, u64 size)
>>
>>    ops :
>>      OPAL_MPIPL_REGISTER_TAG
>>        Kernel metadata pointer. Kernel will send this to OPAL during MPIPL
>>        registration. Post MPIPL, kernel will request for this tag via
>>        mpipl_query_tag API.
>>          src  = kernel metadata address
>>          dest = ignore
>>          size = ignore
>>
>>      OPAL_MPIPL_ADD_RANGE
>>        Add new entry to MPIPL table. Kernel will send src, dest and size.
>>        During MPIPL content from source address is moved to destination address.
>>          src  = Source start address
>>          dest = Destination start address
>>          size = size
>>
>>      OPAL_MPIPL_REMOVE_RANGE
>>        Remove kernel requested entry from MPIPL table.
>>          src  = Source start address
>>          dest = Destination start address
>>          size = ignore
>>
>>      OPAL_MPIPL_REMOVE_ALL
>>        Remove all kernel passed entry from MPIPL table.
>>          src  = ignore
>>          dest = ignore
>>          size = ignore
>>
>>      OPAL_MPIPL_FREE_PRESERVED_MEMORY
>>        Post MPIPL, kernel will indicate OPAL that it has processed dump and
>>        it can clear/release metadata area.
>>          src  = ignore
>>          dest = ignore
>>          size = ignore
>>
>> Return values:
>>    OPAL_SUCCESS   : Operation success
>>    OPAL_PARAMETER : Payload passed invalid data
>>    OPAL_RESOURCE  : Ran out of MDST or MDDT table size
>>    OPAL_HARDWARE  : MPIPL not supported
> 
> Thanks very much for working on this, I'm a lot happier with the API
> now. It would be important if everybody interested can take a look at
> the proposed DT and OPAL call APIs even if you aren't able to review
> code and details carefully.
> 

Thanks!

> Do we undo a level of indirection and make each of these options its
> own OPAL_ call? I think that would be nicer and you'd get proper
> parameters, etc.

I don't think we gain much from individual APIs compared to what we have now.


-Vasant