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

Vasant Hegde hegdevasant at linux.vnet.ibm.com
Thu Aug 16 15:31:12 AEST 2018


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.

I think we should plumb panic path to call  OPAL_REBOOT_OS_ERROR.

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

-Vasant




More information about the Skiboot mailing list