[Skiboot] [PATCH] fast-boot: occ: Re-parse the pstate table during fast-boot

[Stewart Smith]

ppaidipe <ppaidipe at linux.vnet.ibm.com> writes:
> On 2018-02-08 10:14, Stewart Smith wrote:
>> Vaidyanathan Srinivasan <svaidy at linux.vnet.ibm.com> writes:
>>>> I'm just wondering, should this be under an nvram option?
>>> 
>>> The risk actually depends on what we ask OCC to do and hence not
>>> a major config change/risk for OPAL.  I would like to leave it as
>>> default for fast-reboot.  We add slight time factor to rebuild the
>>> relevant device tree.  Given that fast-reboot itself is experimental,
>>> this is a acceptable risk and overhead.
>>> 
>>> If we hit new error/fail scenarios in future, we can add settings.
>>> I would like to roll this into a single knob for fast-reboot like
>>> "safe", "risky" or something that can help us choose what we want to
>>> do in reinit path.  We need not call out OCC reinit as explicit nvram
>>> option at this time.
>> 
>> It's a good question what we should do there... in a secure boot world,
>> we're probably better off as in that case you shouldn't be able to go
>> and poke things into the OCCs to do bad things.
>> 
>> I wonder if we could get an OCC command to "reset back to what you'd be
>> on IPL" or something?
>
> I think this is one of the example failure case where occ is still in
> disabled state after fast reboot. As shilpa mentioned we should be able
> to clear max_occ_reset_count and do the occ re-init.
> https://github.com/open-power/skiboot/issues/49

Yeah, we should probably go down the route of doing that (perhaps we
should do that no matter what? I'm not sure, we'll need to talk to the
OCC team to work out what's the best/correct thing to do).

I've merged the patch to master as of
85a1de35cbe47618e9d4104880f182121806af4d as it seems to be something
decent at least for the time being... although I'm not convinced we
shouldn't either disable it or go through a larger re-init cycle with
the OCC....

-- 
Stewart Smith
OPAL Architect, IBM.