[Skiboot] [PATCH v4 14/18] fadump: Introduce new reboot type

[Vasant Hegde]

On 08/17/2018 10:05 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
>> On 08/07/2018 01:29 PM, Stewart Smith wrote:
>>> Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
>>>> Enhance reboot2 call to support FADUMP. Payload will call this interface
>>>> to initiate fadump.
>>>>
>>>> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
>>>> ---
>>>>    core/platform.c                        | 4 ++++
>>>>    doc/opal-api/opal-cec-reboot-6-116.rst | 7 +++++++
>>>>    include/opal-api.h                     | 1 +
>>>>    3 files changed, 12 insertions(+)
>>>>
>>>> diff --git a/core/platform.c b/core/platform.c
>>>> index 3282227c1..08f05dc9b 100644
>>>> --- a/core/platform.c
>>>> +++ b/core/platform.c
>>>> @@ -101,6 +101,10 @@ static int64_t opal_cec_reboot2(uint32_t reboot_type, char *diag)
>>>>    	case OPAL_REBOOT_FULL_IPL:
>>>>    		disable_fast_reboot("full IPL reboot requested");
>>>>    		return opal_cec_reboot();
>>>> +	case OPAL_REBOOT_MPIPL:
>>>> +		prlog(PR_ERR, "Kernel requested for fadump\n");
>>>> +		assert(false);
>>>> +		break;
>>>>    	default:
>>>>    		prlog(PR_NOTICE, "OPAL: Unsupported reboot request %d\n", reboot_type);
>>>>    		return OPAL_UNSUPPORTED;
>>>> diff --git a/doc/opal-api/opal-cec-reboot-6-116.rst b/doc/opal-api/opal-cec-reboot-6-116.rst
>>>> index 516d4fc01..11cf54aa1 100644
>>>> --- a/doc/opal-api/opal-cec-reboot-6-116.rst
>>>> +++ b/doc/opal-api/opal-cec-reboot-6-116.rst
>>>> @@ -63,6 +63,13 @@ OPAL_REBOOT_FULL_IPL = 2
>>>>    	On platforms that don't support fast reboot, this is equivalent to a
>>>>    	normal reboot.
>>>>
>>>> +OPAL_REBOOT_MPIPL = 3
>>>> +	Request for fadump reboot. Firmware will reboot the system and collect
>>>> +	dump.
>>>> +
>>>> +	On platforms that don't support fadump, this is equivalent to a
>>>> +	normal assert.
>>>
>>> I think a reboot type is the right way to go here, although I was
>>> thinking maybe something not tied to MPIPL itself but something a bit
>>> more generic....
>>>
>>> I'm thinking along the lines of "should a dump be taken"... We have
>>> OPAL_REBOOT_PLATFORM_ERROR for when there's something gone wrong on a
>>> platform level (theoretically not the Operating System's fault), maybe
>>> we want OPAL_REBOOT_OS_ERROR ?
>>
>> Yes. OS_ERROR makes sense. Will fix it.
>>
>>>
>>> With a dump being attempted for OPAL_REBOOT_PLATFORM_ERROR and
>>> OPAL_REBOOT_OS_ERROR reboot types?
>>
>> By default we have disabled xscom_trigger_xstop() in P9. So
>> OPAL_REBOOT_PLATFORM_ERROR
>> will return  to kernel and kernel will call panic path.
> 
> Yeah, I think we could at the least re-enable it and map it to MPIPL (at
> least for the time being)?

Yes.. We can do that.. I will enable this patch later (once base patches merged).

> 
> At least then there'd be some kind of data capture of what went wrong
> rather than our current gathering of absolutely nothing.

Agree.


> 
>> I think we should plumb panic path to call  OPAL_REBOOT_OS_ERROR.
> 
> Yes, agree.
> 
>>> A bit of an unanswered question I have is if we should have a fast
>>> reboot path for gathering a dump, as I'm not sure there's much that
>>> would prevent us doing that?
>>
>> Nothing prevents us from doing it . But do we really need? My understanding is
>> fast reboot is called in normal path (not when we hit some
>> kernel/platform error).
> 
> We'll do a fast reboot even in the event of panic() as it's just hooked
> up to the normal reboot path. We do disable fast reboot in some paths
> though, namely: unrecoverable HMI, platform error, a bunch of internal
> OPAL problems etc.

Hmmm. may be we should plumb panic() path to call MPIPL. Will look into it later.

-Vasant