[Skiboot] [PATCH v8 12/24] MPIPL: Add OPAL API to register for dump
Vasant Hegde
hegdevasant at linux.vnet.ibm.com
Tue Jul 2 20:19:25 AEST 2019
On 06/28/2019 04:40 PM, Nicholas Piggin wrote:
> Vasant Hegde's on June 28, 2019 8:13 pm:
>> 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.
>
> You get proper prototype types though, so the question is what do
> you gain from having a multiplexer API?
Well, I don't really gain anything with either approach. IMO single API is
better as its easy to manage one (and document just one API :-) )
-Vasant
More information about the Skiboot
mailing list