On Thu, Jul 12, 2018 at 11:41:08AM +0100, Grant Likely wrote:
> 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.
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.
>
> Cc: Dong Wei <dong....@arm.com>
> Cc: Alexander Graf <ag...@suse.de>
> Cc: Peter Robinson <pbrobin...@redhat.com>
> Signed-off-by: Grant Likely <grant.lik...@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
>
> _______________________________________________
> Arm.ebbr-discuss mailing list
> arm.ebbr-disc...@arm.com
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
