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

Hari Bathini hbathini at linux.ibm.com
Wed Jul 10 14:50:33 AEST 2019


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...

Thanks
Hari

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


More information about the Skiboot mailing list