public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Sami Mujawar" <sami.mujawar@arm.com>
To: Pranav Madhu <Pranav.Madhu@arm.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>, nd <nd@arm.com>,
	Thomas Abraham <thomas.abraham@arm.com>,
	Leif Lindholm <leif@nuviainc.com>
Subject: Re: [edk2][PATCH V1 1/1] ArmPkg: Handle warm reboot request correctly
Date: Fri, 11 Mar 2022 14:28:25 +0000	[thread overview]
Message-ID: <180d3121-277d-d21f-06cc-ef19dbfe7c91@arm.com> (raw)
In-Reply-To: <DB9PR08MB686015D81AC625E435DB90EB8A0C9@DB9PR08MB6860.eurprd08.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 6651 bytes --]

Hi Pranav,

Please see my response inline marked [SAMI].

Regards,

Sami Mujawar


On 11/03/2022 06:06 AM, Pranav Madhu wrote:
> Hi Sami,
>
> Thanks for your comments. Please find my reply inline.
>
> Regards,
> Pranav
>
>> -----Original Message-----
>> From: Sami Mujawar <Sami.Mujawar@arm.com>
>> Sent: Thursday, March 10, 2022 9:01 PM
>> To: Pranav Madhu <Pranav.Madhu@arm.com>; devel@edk2.groups.io
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; nd <nd@arm.com>
>> Subject: Re: [edk2][PATCH V1 1/1] ArmPkg: Handle warm reboot request
>> correctly
>>
>> Hi Pranav,
>>
>> Thank you for this patch.
>>
>> Please find my response inline marked [SAMI].
>>
>> Regards,
>>
>> Sami Mujawar
>>
>>
>> On 10/03/2022 01:10 PM, Pranav Madhu wrote:
>>> The warm reboot requests are mapped to cold reboot as the power
>>> control module was not capable of handling the warm reboot requests in
>>> the legacy implementation. The support for warm reboot support is
>>> added into the power control module. To support warm reset, update
>>> ArmPsciResetSystemLib, and there by invoke the PSCI call with
>>> parameters for warm reboot.
>>>
>>> Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
>>> ---
>>>    ArmPkg/Include/IndustryStandard/ArmStdSmc.h                  | 1 +
>>>    ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.c | 7
>> +++++--
>>>    2 files changed, 6 insertions(+), 2 deletions(-)
>>>
>>> Link to github branch for this patch -
>>> https://github.com/Pranav-Madhu/edk2/tree/topics/warm_reboot
>>>
>>> diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>>> b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>>> index 655edc21b205..c9059dead6e9 100644
>>> --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>>> +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>>> @@ -93,6 +93,7 @@
>>>    #define ARM_SMC_ID_PSCI_MIGRATE_AARCH32        0x84000005
>>>    #define ARM_SMC_ID_PSCI_SYSTEM_OFF             0x84000008
>>>    #define ARM_SMC_ID_PSCI_SYSTEM_RESET           0x84000009
>>> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64  0xc4000012
>>>
>>>    /* The current PSCI version is:  0.2 */
>>>    #define ARM_SMC_PSCI_VERSION_MAJOR  0 diff --git
>>> a/ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.c
>>> b/ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.c
>>> index 7bcd34849507..27e048ba0f7a 100644
>>> --- a/ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.c
>>> +++ b/ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.c
>>> @@ -45,10 +45,13 @@ LibResetSystem (
>>>      ARM_SMC_ARGS  ArmSmcArgs;
>>>
>>>      switch (ResetType) {
>>> +    case EfiResetWarm:
>>> +      ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64;
>>> +      ArmSmcArgs.Arg1 = 0;
>>> +      ArmSmcArgs.Arg2 = 0;
>>> +      break;
>> [SAMI] SYSTEM_RESET2 is an optional feature and if not supported would
>> return NOT_SUPPORTED. So, if a platform does not support SYSTEM_RESET2,
>> should the code here fall back to SYSTEM_RESET?
>> According to the PSCI specification, it is the responsibility of the OS to check
>> that SYSTEM_RESET2 is supported before calling SYSTEM_RESET2 (I believe this
>> is applicable for the case where UEFI is not used to boot the OS). However, if
>> the runtime service ResetSystem() is invoked by the OS requesting a warm
>> reset, is it not the firmware's responsibility to ensure that SYSTEM_RESET2 is
>> supported? Any thoughts?
> Right, from PSCI specification, what I understood is before invoking SYSTEM_RESET2, the OS should query the PSCI capabilities using PSCI_FEATURES for SYSTEM_RESET2. The OS should invoke RESET2 only if PSCI_FEATURES returns 0. From spec, what I understood is it is not the responsibility of firmware. If OS issue RESET2 without querying FEATURES, the only option for firmware is to return NOT_SUPPORTED.

[SAMI] There are 2 scenarios:
1. A boot loader other than UEFI is used to boot the OS.
In this case the OS shall directly call the PSCI interface to reboot.
For this scenario the Linux kernel code performs the required checks and 
makes the appropriate PSCI call see 
https://elixir.bootlin.com/linux/v5.16.13/source/drivers/firmware/psci/psci.c#L299

2. UEFI is used to boot the OS.
In this case the UEFI Runtime Services ResetSystem() will be invoked by 
the OS to initiate a reboot.
In this scenario the checks performed by the OS to see if SYSTEM_RESET2 
is supported are irrelevant. It is the firmware that needs to perform 
the check. Although
the PSCI specification section '5.12.4 Caller responsibilities' mentions 
'The calling OS...'; this is an example, and in context with the current 
usage scenario, it is the
responsibility of the firmware (the Caller) to perform these checks. 
Otherwise this can result in failures on platforms that do not implement 
the SYSTEM_RESET2 feature.
The relevant code in the Linux kernel for this scenario can be seen at:
https://elixir.bootlin.com/linux/v5.16.13/source/drivers/firmware/efi/reboot.c#L13
https://elixir.bootlin.com/linux/v5.16.13/source/drivers/firmware/efi/runtime-wrappers.c#L412

I also noticed that there are 2 versions of the ResetSystem library:
[A] EfiResetSystemLib based implementation
       This is 
ArmPkg\Library\ArmPsciResetSystemLib\ArmPsciResetSystemLib.inf which 
links with EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
[B] ResetSystemLib based implementation
       This is 
ArmPkg\Library\ArmSmcPsciResetSystemLib\ArmSmcPsciResetSystemLib.inf 
which links with 
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf

I can see that [A] EfiResetSystemLib is only used by:
- Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
- Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
- Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc

Moreover, the commit b2c55e732888fd721f5235a820b1d1c45209992d states 
that the ArmSmcPsciResetSystemLib.inf ([B] ResetSystemLib) was introduced
with the intention to replace the EfiResetSystemLib based implementation 
that is deprecated now that we have decided that there is
no longer a reason to keep a different ResetSystem() implementation 
under EmbeddedPkg.

Considering this, I don't think this patch should modify 
ArmPkg\Library\ArmPsciResetSystemLib.
SgiPkg (and if possible other platforms) should consider moving to 
ResetSystemLib based implementation.

[/SAMI]
>> [/SAMI]
>>>        case EfiResetPlatformSpecific:
>>>        // Map the platform specific reset as reboot
>>> -    case EfiResetWarm:
>>> -    // Map a warm reset into a cold reset
>>>        case EfiResetCold:
>>>          // Send a PSCI 0.2 SYSTEM_RESET command
>>>          ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET;


[-- Attachment #2: Type: text/html, Size: 10373 bytes --]

  reply	other threads:[~2022-03-11 14:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 13:10 [edk2][PATCH V1 1/1] ArmPkg: Handle warm reboot request correctly Pranav Madhu
2022-03-10 15:26 ` Ard Biesheuvel
2022-03-11  6:40   ` Pranav Madhu
2022-03-10 15:30 ` Sami Mujawar
2022-03-11  6:06   ` Pranav Madhu
2022-03-11 14:28     ` Sami Mujawar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-11  6:52 Pranav Madhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=180d3121-277d-d21f-06cc-ef19dbfe7c91@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox