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. +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.
On Thu, Jul 12, 2018 at 11:41:08AM +0100, Grant Likely wrote:
I'm really struggling to wrap my head around this one.
How does incorrectly describing a non-volatile but non-modifiable variable as volatile help the OS do the right thing?
The OS will discover the variable is non-modifiable when it tried to set it. Won't the current proposal mislead standards compliant use of GetVariable()? For example does it it makes standards compliant code *more* likely to call SetVariable() in order to fix up a variable that it thinks was incorrectly set with the NON_VOLATILE attribute.
Daniel.
My 2 cents
This is really good statement for specification. I believe this will solve the problem of shared storage too.
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.
Grant,
I think the variables are defined by the specs as either non-volatile or volatile. It should not be changing.
- DW - -----Original Message----- From: Grant Likely Sent: Thursday, July 12, 2018 3:41 AM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Cc: nd nd@arm.com; Grant Likely Grant.Likely@arm.com; Dong Wei Dong.Wei@arm.com; Alexander Graf agraf@suse.de; Peter Robinson pbrobinson@redhat.com Subject: [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. +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. -- 2.13.0
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 12/07/2018 15:46, Dong Wei wrote:
Grant,
I think the variables are defined by the specs as either non-volatile or volatile. It should not be changing.
Alright, I'm looking for alternate proposals then.
How should EBBR support platforms which cannot write non-volatile variables from runtime services?
g.
boot-architecture@lists.linaro.org