[Skiboot] [PATCH v2 1/2] mpipl: Delay MPIPL registration until OPAL init is complete

[Vasant Hegde]

On 6/23/20 7:18 AM, Oliver O'Halloran wrote:
> On Wed, Jun 17, 2020 at 5:16 PM Vasant Hegde
> <hegdevasant at linux.vnet.ibm.com> wrote:
>>
>> If OPAL boot fails after MPIPL init (opal_mpipl_init()) then we call MPIPL
>> boot instead of reboot. BMC is not aware of MPIPL. Hence it may result in
>> continuous MPIPL loop (boot -> crash -> MPIPL -> boot).
>>
>> If OPAL boot fails (before loading kernel) then its better to call reboot.
>> So that BMC can detect `n` number of boot failures (generally n = 3) and
>> stop booting. That way we can avoid continuous loop.
>>
>> This patch moves MPIPL init to the end of init process (just before starting
>> kernel). So that if we fail to boot OPAL we call normal reboot.
>>
>> Also this patch introduces new function to detect MPIPL is enabled or not
>> (is_mpipl_enabled()). And in assert() path we check for this function
>> instead of `dump` DT node. So that it will make sure we will not call
>> MPIPL until opal_mpipl_init is complete.
> 
> Why do we even allow repeated MPIPLs? Just seems like a good way to
> get stuck in a boot loop.
> 
> This patch sorta helps, but we've got the same problem if we happen to
> hit a crash while petitboot is running. Maybe we should only MPIPL if
> the host kernel explicitly requests one rather than hacking it into
> the termination path like we're doing now.
> 

Yes. We should improve crash path.

I think for now this is good enough. If petitboot crashes it will call xstop() 
and BMC
can detect it.

-Vasant