<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/07/19 11:22 AM, Oliver O'Halloran
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOSf1CFgSWmBu4v3g4r-0VhGZEF405csCFdENOATnS92tONUjA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Wed, Jul 10, 2019 at 2:50 PM Hari Bathini <a class="moz-txt-link-rfc2396E" href="mailto:hbathini@linux.ibm.com"><hbathini@linux.ibm.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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?
</pre>
</blockquote>
<pre>
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
(<a class="moz-txt-link-freetext" href="https://patchwork.ozlabs.org/patch/1122300/">https://patchwork.ozlabs.org/patch/1122300/</a>).
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
</pre>
</body>
</html>