My 2 cents
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com [mailto:arm.ebbr-discuss- bounces@arm.com] On Behalf Of Grant Likely Sent: Thursday, July 12, 2018 4:11 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss@arm.com Cc: nd@arm.com Subject: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
Add details on what to do if the platform is unable to set persistent variables in runtime services. The idea here is that the GetVariable() and SetVariable() APIs should continue to work, and the OS can obtain all the variable settings, but if it cannot be written then the NON_VOLATILE attribute is cleared so the OS knows that persistence is not available.
Cc: Dong Wei dong.wei@arm.com Cc: Alexander Graf agraf@suse.de Cc: Peter Robinson pbrobinson@redhat.com Signed-off-by: Grant Likely grant.likely@arm.com
Alex/Peter: Does this approach work for you? I tried to come up with something that is faithful to the spec, gives the OS information that non-volatile variables aren't available, but still have the ability to query the boot environment.
Dong: Is this an appropriate way to use {Get,Set}Variable()?
Cheers, g.
source/chapter2-uefi.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b6843e..57594bc 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,13 +197,13 @@ command: Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI.
-Set Variable
-Non-volatile UEFI variables must persist across reset, and emulated variables - in RAM are not permitted. -The UEFI Runtime Services must be able to update the variables directly without -the aid of the Operating System. +Runtime Variable Access +-----------------------
-.. note:: This normally requires dedicated storage for UEFI variables that is
- not directly accessible from the Operating System.
+Non-volatile UEFI variables must persist across reset. +If the platform is incapable of updating non-volatile variables from +Runtime Services then it must clear the EFI_VARIABLE_NON_VOLATILE +attribute from all non-volatile variables when ExitBootServices() is called.
This is really good statement for specification. I believe this will solve the problem of shared storage too.
+Similarly, if non-volatile variables cannot be set from Runtime +Services, then +SetVariable() must return EFI_INVALID_PARAMETER if the +EFI_VARIABLE_NON_VOLATILE attribute is set.
You meant EFI_VARIABLE_NON_VOLATILE is reset ?
Also I am not sure, if UEFI specs says return error EFI_INVALID_PARAMETER if variable is volatile
Can we add statement for GetVariable too, UEFI Specs says " Variables that have runtime access but that are not nonvolatile are read-only data variables once ExitBootServices() is performed."
So this means, firmware (edk2 or u-boot) needs to take care of this. Simply caching variables in RAM could solve the purpose as SetVariable is not allowed.
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com