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

[Oliver O'Halloran]

On Wed, Jul 10, 2019 at 5:11 PM Hari Bathini <hbathini at linux.ibm.com> wrote:
>
> 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 don't see a problem with either approach. Say we do the "naive"
thing and change the API to this:

enum opal_mpipl_tag {
OPAL_MPIPL_TAG_PROC_DATA,
OPAL_MPIPL_TAG_CORE,
OPAL_MPIPL_TAG_KERNEL,
}

And fetch the tags with:

int64_t opal_mpipl_query_tag(enum opal_mpipl_tag tag, uint64_t *tag_value);

Is this any more complex, or less flexible, than the current
query-and-iterate approach? The kernel is going to ignore  tags that
it doesn't recognise in either case.

Anyway, take that, add an extra tag that's set by the production
kernel to indicate where preserved memory starts and
CONFIG_FADUMP_PRESERVE boils down to:

rc = opal_mpipl_query_tag(OPAL_MPIPL_TAG_PRESERVE_LIMIT, &limit);
if(!rc)
    memblock_reserve(limit, memblock_end_of_DRAM());

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

No one is suggesting adding any metadata handling to OPAL. So I don't
understand what you're complaining about here.

> We should get that requirement documented though..
>
> Thanks
> Hari
>