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

[Oliver O'Halloran]

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?

Oliver