On 9/2/20 9:52 AM, Laszlo Ersek wrote:

On 09/02/20 05:35, wenyi,xie via groups.io wrote:

InitEmuNonVolatileVariableStore or InitRealNonVolatileVariableStore
will be used to initial non-volatile variable according to value of
PcdEmuVariableNvModeEnable.
How do I know which one I should use?

The DEC file says:

   ## Indicates if Variable driver will enable emulated variable NV mode.<BR><BR>
   #  If this PCD is configured to dynamic, its value should be set before Variable driver starts to work,<BR>
   #  otherwise default value will take effect.<BR>
   #   TRUE  - An EMU variable NV storage will be allocated or reserved for NV variables.<BR>
   #   FALSE - No EMU variable NV storage will be allocated or reserved for NV variables.<BR>
   # @Prompt EMU variable NV mode enable.
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE|BOOLEAN|0x01100001

After some brief checks, the default FALSE value means that you have a
flash chip for storing non-volatile variables, a platform driver that
exposes the FVB (Firmware Volume Block) protocol on top of the flash
chip, and your platform includes the universal FTW (fault tolerant
write) protocol / driver on top of FVB. Whereas TRUE means that the
non-volatile storage will be emulated in runtime data type memory.

So, if your platform has a flash chip or other permanent storage you can
use for storing non-volatile UEFI variables, and you are able to provide
an FVB driver for that storage in your platform firmware, then stick
with the default FALSE value (and include the FTW driver too in your DSC
/ FDF files).

(CC'ing Ard because ArmVirtXen uses

   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|TRUE
)

Thanks for the CC.

To clarify the Xen situation: we never got around to implementing this properly for Xen; Xen relies heavily on paravirtualization, and so it would make little sense to implement NOR flash emulation - instead, something modeled after the [S]MM variable runtime DXE would make much more sense, where the get/set variable calls are simply relayed to another execution context (which would be dom0 user space in the case of Xen, I presume)

Until such a driver materializes, we are stuck with the current emulated varstore support, which loses its memory at a reboot.


.