[Skiboot] [PATCH v8 20/24] MPIPL: Add OPAL API to query saved tags

[Hari Bathini]

On 10/07/19 11:22 AM, Oliver O'Halloran wrote:
> On Wed, Jul 10, 2019 at 2:50 PM Hari Bathini <hbathini at linux.ibm.com> wrote:
>>
>> On 10/07/19 9:22 AM, Michael Neuling wrote:
>>
>> On Tue, 2019-07-09 at 20:53 +0530, Vasant Hegde wrote:
>>
>> On 07/09/2019 03:33 PM, Oliver O'Halloran wrote:
>>
>> On Sun, 2019-06-16 at 22:40 +0530, Vasant Hegde wrote:
>>
>> [...]
>>
>> OS won't guess anything about firmware memory usage. In fact it won't care
>> about
>> firmware memory except `fw-load-area`.
>>
>> We already communicate some of that
>> information via the fw-load-area DT property, but that only contains the
>> ranges where skiboot loads the kernel and initrd (0x2000_000...0x2fff_ffff).
>>
>> OS needs to know about these memory ranges *only*...as first kernel may use
>> these
>> memory. If it uses it should take care of reserving destination memory to
>> preserve these
>> memory and pass it during MPIPL registration.
>>
>> Odds are hostboot doesn't use *that* much memory, but the petitboot kernel
>> can
>>
>> As mentioned above kernel need not worry about hostboot memory usage...as its
>> part of reserved-memory ranges.
>>
>> Vasant,
>>
>> I think you may have missed Oliver's point in the above.
>>
>> The Petitboot kernel needs some amount space to operate. In your current patch
>> series, the amount of space "firmware" is allowed to use is hard-wired by the
>> crashing kernel. Olivers point is that this size should be defined dynamically
>> by firmware, not hard-wired into the crashing kernel.
>>
>> If we every change petitboot or some other component of the firmware so that it
>> needs to use more memory, then the crashing kernel won't have any way of
>> discovering that and it won't allocate enough space for this process to start.
>>
>> Mikey, the memory to be used by petitboot kernel is restricted by crashkernel parameter.
>> This is not hard-wired. This has to be configured by the user (a systemadmin, generally).
>> The value is typically something that has to be sufficient to boot a petitboot kernel and
>> also the production kernel to capture the dump...
> Right, the problem is that the metadata set by the production kernel
> metadata *must* be in the format that the petitboot kernel expects.
> The point of making OPAL oblivious to the contents of the kernel tag
> was to allow the production kernel to define it's own metadata format
> rather than having one imposed on it by the platform.
>
> Previously the platform imposed structure was defined by the OPAL API
> and we "fixed" that by moving to the tags API where OPAL is oblivious
> of the kernel metadata. This is an improvement, but the way the tag
> API is structured means that we now have a platform imposed structure
> coming from the petitboot kernel which defeats the point of changing
> the API in the first place.
>
> As far as I can tell the only reason we've done this is to allow the
> petitboot kernel to parse the metadata to work out how much memory
> it's allowed to trash. Why not just solve that very specific problem
> and let the production kernel do whatever it likes?
>
Sorry, if I was not clear but that is how it is. Metadata is setup by
production kernel based on user configuration and after crash, petitboot kernel
looks for this metadata to work out how much memory it is allowed to trash
(https://patchwork.ozlabs.org/patch/1122300/).

As for the type field in the metadata, that requirement comes from the need to
keep metadata retrieval simple. Without a type field, we need to have a predefined
ordering or kernel has to remember which tag no. corresponds to which data type.
While the former seems naive, the later, brings with it a need to handle kernel
metadata separately as we need to get that data before processing tags..

I would prefer it the current way as it is simple and we do any special
handling for kernel metadata..

We should get that requirement documented though..

Thanks
Hari

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20190710/095a067c/attachment-0001.htm>