Discussion:
[edk2] Question about FaultTolerantWriteDxe and VariableRuntimeDxe
Hawk
2012-03-31 11:33:52 UTC
Permalink
Hi All,



Here is one question about the dispatcher order of FaultTolerantWriteDxe and
VariableRuntimeDxe under MdeModulePkg\Universal\Variable\RuntimeDxe.

As you know VariableRuntime driver needs to use the protocol
"EFI_FAULT_TOLERANT_WRITE_PROTOCOL" to reclaim the storage space, which is
produced by FaultTolerantWriteDxe, when the variable storage is full. So our
understanding is FaultTolerantWriteDxe should be dispatched before
VariableRuntimeDxe to recover from illegal state in DXE phase, if there is
any unexpected failure occurs in reclaim process. But we observed this
requirement is not explicitly defined in dependency of VariableRuntimeDxe.
Is there any other consideration about this?



BTW, With EDK codebase, we can observed that this is just done in this way.





Thanks,

Hawk.
Andrew Fish
2012-03-31 15:15:20 UTC
Permalink
Hawk,

It looks like edk2 Variable driver registers an event called FtwNotificationEvent() so it can detect when the FaultTolerantWrite protocol becomes available.

If you look at the variable driver when it installs it publishes gEfiVariableArchProtocolGuid, and this combined with a dependency expression of TRUE this gives read access to variables early in the DXE phase. When the FTW protocol is available the variable driver publishes gEfiVariableWriteArchProtocolGuid.

This means if your DXE driver needs to write to the variable store it should depend on gEfiVariableWriteArchProtocolGuid. If your driver only needs read access it should depend on gEfiVariableArchProtocolGuid. This is defined in the latest PI spec.

Andrew Fish
Post by Hawk
Hi All,
Here is one question about the dispatcher order of FaultTolerantWriteDxe and VariableRuntimeDxe under MdeModulePkg\Universal\Variable\RuntimeDxe.
As you know VariableRuntime driver needs to use the protocol “EFI_FAULT_TOLERANT_WRITE_PROTOCOL” to reclaim the storage space, which is produced by FaultTolerantWriteDxe, when the variable storage is full. So our understanding is FaultTolerantWriteDxe should be dispatched before VariableRuntimeDxe to recover from illegal state in DXE phase, if there is any unexpected failure occurs in reclaim process. But we observed this requirement is not explicitly defined in dependency of VariableRuntimeDxe. Is there any other consideration about this?
BTW, With EDK codebase, we can observed that this is just done in this way.
Thanks,
Hawk.
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Hawk
2012-03-31 15:38:13 UTC
Permalink
Andrew,



Thanks for your information.



My concern is that FTW driver should be dispatched before variable driver to
handle any illegal case. For example, a power failure may just occur after
variable storage is erased to FF, but before the defragmented variable data
is programmed, during the process of variable reclaim. Then in the next boot
circle, the variable driver can¡¯t handle this case but simply return error
(refer to VariableCommonInitialize() in variable.c). Even FaultTolerant
driver just has capability to handle this case, but it may have no chance to
run as the dispatching may stopped.



Thanks,

Hawk.



·¢ŒþÈË: Andrew Fish [mailto:***@apple.com]
·¢ËÍʱŒä: 2012Äê3ÔÂ31ÈÕ 23:15
ÊÕŒþÈË: edk2-***@lists.sourceforge.net
Ö÷Ìâ: Re: [edk2] Question about FaultTolerantWriteDxe and VariableRuntimeDxe



Hawk,



It looks like edk2 Variable driver registers an event called
FtwNotificationEvent() so it can detect when the FaultTolerantWrite protocol
becomes available.



If you look at the variable driver when it installs it publishes
gEfiVariableArchProtocolGuid, and this combined with a dependency expression
of TRUE this gives read access to variables early in the DXE phase. When the
FTW protocol is available the variable driver publishes
gEfiVariableWriteArchProtocolGuid.



This means if your DXE driver needs to write to the variable store it should
depend on gEfiVariableWriteArchProtocolGuid. If your driver only needs read
access it should depend on gEfiVariableArchProtocolGuid. This is defined in
the latest PI spec.



Andrew Fish



On Mar 31, 2012, at 4:33 AM, Hawk wrote:





Hi All,



Here is one question about the dispatcher order of FaultTolerantWriteDxe and
VariableRuntimeDxe under MdeModulePkg\Universal\Variable\RuntimeDxe.

As you know VariableRuntime driver needs to use the protocol
¡°EFI_FAULT_TOLERANT_WRITE_PROTOCOL¡± to reclaim the storage space, which is
produced by FaultTolerantWriteDxe, when the variable storage is full. So our
understanding is FaultTolerantWriteDxe should be dispatched before
VariableRuntimeDxe to recover from illegal state in DXE phase, if there is
any unexpected failure occurs in reclaim process. But we observed this
requirement is not explicitly defined in dependency of VariableRuntimeDxe.
Is there any other consideration about this?



BTW, With EDK codebase, we can observed that this is just done in this way.





Thanks,

Hawk.

----------------------------------------------------------------------------
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___________________________________________
Andrew Fish
2012-03-31 16:39:41 UTC
Permalink
Post by Hawk
Andrew,
Thanks for your information.
My concern is that FTW driver should be dispatched before variable driver to handle any illegal case. For example, a power failure may just occur after variable storage is erased to FF, but before the defragmented variable data is programmed, during the process of variable reclaim. Then in the next boot circle, the variable driver can¡¯t handle this case but simply return error (refer to VariableCommonInitialize() in variable.c). Even FaultTolerant driver just has capability to handle this case, but it may have no chance to run as the dispatching may stopped.
Thanks I understand your point now. Yes there is a case where the ready only service of the driver may not work. If I remember we ran into issues of drivers needing read access to the variable store early in the boot process so delaying the entire variable services was not desirable. But you also bring up a good point.

If drivers want the more reliable quality of service for reads (your example case) then that driver should depend on gEfiVariableWriteArchProtocolGuid.This is an interesting point and maybe we should document this in the PI spec. I will bring it up with the spec committee.

Thanks,

Andrew
Post by Hawk
Thanks,
Hawk.
·¢ËÍʱŒä: 2012Äê3ÔÂ31ÈÕ 23:15
Ö÷Ìâ: Re: [edk2] Question about FaultTolerantWriteDxe and VariableRuntimeDxe
Hawk,
It looks like edk2 Variable driver registers an event called FtwNotificationEvent() so it can detect when the FaultTolerantWrite protocol becomes available.
If you look at the variable driver when it installs it publishes gEfiVariableArchProtocolGuid, and this combined with a dependency expression of TRUE this gives read access to variables early in the DXE phase. When the FTW protocol is available the variable driver publishes gEfiVariableWriteArchProtocolGuid.
This means if your DXE driver needs to write to the variable store it should depend on gEfiVariableWriteArchProtocolGuid. If your driver only needs read access it should depend on gEfiVariableArchProtocolGuid. This is defined in the latest PI spec.
Andrew Fish
Hi All,
Here is one question about the dispatcher order of FaultTolerantWriteDxe and VariableRuntimeDxe under MdeModulePkg\Universal\Variable\RuntimeDxe.
As you know VariableRuntime driver needs to use the protocol ¡°EFI_FAULT_TOLERANT_WRITE_PROTOCOL¡± to reclaim the storage space, which is produced by FaultTolerantWriteDxe, when the variable storage is full. So our understanding is FaultTolerantWriteDxe should be dispatched before VariableRuntimeDxe to recover from illegal state in DXE phase, if there is any unexpected failure occurs in reclaim process. But we observed this requirement is not explicitly defined in dependency of VariableRuntimeDxe. Is there any other consideration about this?
BTW, With EDK codebase, we can observed that this is just done in this way.
Thanks,
Hawk.
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
nicolas
2012-04-01 02:02:26 UTC
Permalink
hi, Hawk:

"For example, a power failure may just occur after variable storage is erased to FF, but before the defragmented variable data is programmed, during the process of variable reclaim. "



In this example, i think letting variable dxe driver continues doing reclaim operation is meaningless in next boot cycle .

Because PEI Phase could not get any useful variables during the next boot cycle, it would cause dxe phase not stable.

And it could not assure defragmented variables not be damaged during a occasional power failure.



best wishes

发件人: Andrew Fish [mailto:***@apple.com]
发送时闎:2012幎4月1日 0:40
收件人: edk2-***@lists.sourceforge.net
䞻题: Re: [edk2] 答倍: Question about FaultTolerantWriteDxe and VariableRuntimeDxe



On Mar 31, 2012, at 8:38 AM, Hawk wrote:





Andrew,



Thanks for your information.



My concern is that FTW driver should be dispatched before variable driver to handle any illegal case. For example, a power failure may just occur after variable storage is erased to FF, but before the defragmented variable data is programmed, during the process of variable reclaim. Then in the next boot circle, the variable driver cant handle this case but simply return error (refer to VariableCommonInitialize() in variable.c). Even FaultTolerant driver just has capability to handle this case, but it may have no chance to run as the dispatching may stopped.



Thanks I understand your point now. Yes there is a case where the ready only service of the driver may not work. If I remember we ran into issues of drivers needing read access to the variable store early in the boot process so delaying the entire variable services was not desirable. But you also bring up a good point.



If drivers want the more reliable quality of service for reads (your example case) then that driver should depend on gEfiVariableWriteArchProtocolGuid.This is an interesting point and maybe we should document this in the PI spec. I will bring it up with the spec committee.



Thanks,



Andrew







Thanks,

Hawk.



ȋ: Andrew Fish [mailto:***@apple.com]
ˍʱ䌳pan lang="EN-US">: 2012Ī3Ԃ31ȕ 23:15
ʕȋ: edk2-***@lists.sourceforge.net
Ö·Ì¢: Re: [edk2] Question about FaultTolerantWriteDxe and VariableRuntimeDxe



Hawk,



It looks like edk2 Variable driver registers an event called FtwNotificationEvent() so it can detect when the FaultTolerantWrite protocol becomes available.



If you look at the variable driver when it installs it publishes gEfiVariableArchProtocolGuid, and this combined with a dependency expression of TRUE this gives read access to variables early in the DXE phase. When the FTW protocol is available the variable driver publishes gEfiVariableWriteArchProtocolGuid.



This means if your DXE driver needs to write to the variable store it should depend on gEfiVariableWriteArchProtocolGuid. If your driver only needs read access it should depend on gEfiVariableArchProtocolGuid. This is defined in the latest PI spec.



Andrew Fish



On Mar 31, 2012, at 4:33 AM, Hawk wrote:






Hi All,



Here is one question about the dispatcher order of FaultTolerantWriteDxe and VariableRuntimeDxe under MdeModulePkg\Universal\Variable\RuntimeDxe.

As you know VariableRuntime driver needs to use the protocol EFI_FAULT_TOLERANT_WRITE_PROTOCOL to reclaim the storage space, which is produced by FaultTolerantWriteDxe, when the variable storage is full. So our understanding is FaultTolerantWriteDxe should be dispatched before VariableRuntimeDxe to recover from illegal state in DXE phase, if there is any unexpected failure occurs in reclaim process. But we observed this requirement is not explicitly defined in dependency of VariableRuntimeDxe. Is there any other consideration about this?



BTW, With EDK codebase, we can observed that this is just done in this way.





Thanks,

Hawk.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Andrew Fish
2012-04-01 02:43:29 UTC
Permalink
Post by nicolas
"For example, a power failure may just occur after variable storage is erased to FF, but before the defragmented variable data is programmed, during the process of variable reclaim. "
In this example, i think letting variable dxe driver continues doing reclaim operation is meaningless in next boot cycle .
Because PEI Phase could not get any useful variables during the next boot cycle, it would cause dxe phase not stable.
And it could not assure defragmented variables not be damaged during a occasional power failure.
Since by definition we have no variable writes in PEI a PEIM should function correctly if a variable is missing. A safe default value should always be used by the PEIM if the variable read fails.

Thanks,

Andrew
Post by nicolas
best wishes
发送时闎: 2012幎4月1日 0:40
䞻题: Re: [edk2] 答倍: Question about FaultTolerantWriteDxe and VariableRuntimeDxe
Andrew,
Thanks for your information.
My concern is that FTW driver should be dispatched before variable driver to handle any illegal case. For example, a power failure may just occur after variable storage is erased to FF, but before the defragmented variable data is programmed, during the process of variable reclaim. Then in the next boot circle, the variable driver cant handle this case but simply return error (refer to VariableCommonInitialize() in variable.c). Even FaultTolerant driver just has capability to handle this case, but it may have no chance to run as the dispatching may stopped.
Thanks I understand your point now. Yes there is a case where the ready only service of the driver may not work. If I remember we ran into issues of drivers needing read access to the variable store early in the boot process so delaying the entire variable services was not desirable. But you also bring up a good point.
If drivers want the more reliable quality of service for reads (your example case) then that driver should depend on gEfiVariableWriteArchProtocolGuid.This is an interesting point and maybe we should document this in the PI spec. I will bring it up with the spec committee.
Thanks,
Andrew
Thanks,
Hawk.
ˍʱ䌳pan lang="EN-US">: 2012Ī3Ԃ31ȕ 23:15
Ö·Ì¢: Re: [edk2] Question about FaultTolerantWriteDxe and VariableRuntimeDxe
Hawk,
It looks like edk2 Variable driver registers an event called FtwNotificationEvent() so it can detect when the FaultTolerantWrite protocol becomes available.
If you look at the variable driver when it installs it publishes gEfiVariableArchProtocolGuid, and this combined with a dependency expression of TRUE this gives read access to variables early in the DXE phase. When the FTW protocol is available the variable driver publishes gEfiVariableWriteArchProtocolGuid.
This means if your DXE driver needs to write to the variable store it should depend on gEfiVariableWriteArchProtocolGuid. If your driver only needs read access it should depend on gEfiVariableArchProtocolGuid. This is defined in the latest PI spec.
Andrew Fish
Hi All,
Here is one question about the dispatcher order of FaultTolerantWriteDxe and VariableRuntimeDxe under MdeModulePkg\Universal\Variable\RuntimeDxe.
As you know VariableRuntime driver needs to use the protocol EFI_FAULT_TOLERANT_WRITE_PROTOCOL to reclaim the storage space, which is produced by FaultTolerantWriteDxe, when the variable storage is full. So our understanding is FaultTolerantWriteDxe should be dispatched before VariableRuntimeDxe to recover from illegal state in DXE phase, if there is any unexpected failure occurs in reclaim process. But we observed this requirement is not explicitly defined in dependency of VariableRuntimeDxe. Is there any other consideration about this?
BTW, With EDK codebase, we can observed that this is just done in this way.
Thanks,
Hawk.
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Loading...