summaryrefslogtreecommitdiff
path: root/MdeModulePkg/Include/Guid/FaultTolerantWrite.h
diff options
context:
space:
mode:
authorStar Zeng <star.zeng@intel.com>2013-07-03 09:08:40 +0000
committerlzeng14 <lzeng14@6f19259b-4bc3-4df7-8a09-765794883524>2013-07-03 09:08:40 +0000
commit3e02ebb2bbe0fd4da880511b1f35951e1c4b8404 (patch)
tree95fc155e9d76e163cd295db373734cc276f4abc6 /MdeModulePkg/Include/Guid/FaultTolerantWrite.h
parent70066a82a54bd5136556dff3ea76dff035a3aca3 (diff)
downloadedk2-platforms-3e02ebb2bbe0fd4da880511b1f35951e1c4b8404.tar.xz
MdeModulePkg: Variable drivers robustly handle crashes during Reclaim().
PEI variable implementation checks only the variable header signature for validity. This does not seem robust if system crash occurred during previous Reclaim() operation. If the crash occurred while FTW was rewriting the variable FV, the signature could be valid even though the rest of the FV isn't valid. Solution: Add a FaultTolerantWritePei driver to check and provide the FTW last write status, then PEI variable and early phase(before FTW protocol ready) of DXE variable can check the status and determine if all or partial variable data has been backed up in spare block, and then use the backed up data. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14454 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'MdeModulePkg/Include/Guid/FaultTolerantWrite.h')
-rw-r--r--MdeModulePkg/Include/Guid/FaultTolerantWrite.h54
1 files changed, 54 insertions, 0 deletions
diff --git a/MdeModulePkg/Include/Guid/FaultTolerantWrite.h b/MdeModulePkg/Include/Guid/FaultTolerantWrite.h
new file mode 100644
index 0000000000..cb7b454b2b
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/FaultTolerantWrite.h
@@ -0,0 +1,54 @@
+/** @file
+ Define the GUID gEdkiiFaultTolerantWriteGuid that will be used to build
+ FAULT_TOLERANT_WRITE_LAST_WRITE_DATA GUID hob and install PPI to inform the check
+ for FTW last write data has been done. The GUID hob will be only built if FTW last write was
+ still in progress with SpareComplete set and DestinationComplete not set.
+
+Copyright (c) 2013, Intel Corporation. All rights reserved.<BR>
+This program and the accompanying materials are licensed and made available under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _FAULT_TOLERANT_WRITE_H_
+#define _FAULT_TOLERANT_WRITE_H_
+
+#define EDKII_FAULT_TOLERANT_WRITE_GUID \
+ { \
+ 0x1d3e9cb8, 0x43af, 0x490b, { 0x83, 0xa, 0x35, 0x16, 0xaa, 0x53, 0x20, 0x47 } \
+ }
+
+//
+// FTW Last write data. It will be used as gEdkiiFaultTolerantWriteGuid GUID hob data.
+//
+typedef struct {
+ ///
+ /// Target address to be updated in FTW last write.
+ ///
+ EFI_PHYSICAL_ADDRESS TargetAddress;
+ ///
+ /// Spare address to back up the updated buffer.
+ ///
+ EFI_PHYSICAL_ADDRESS SpareAddress;
+ ///
+ /// The length of data that have been backed up in spare block.
+ /// It is also the length of target block that has been erased.
+ ///
+ UINT64 Length;
+} FAULT_TOLERANT_WRITE_LAST_WRITE_DATA;
+
+//
+// This GUID will be used to install PPI to inform the check for FTW last write data has been done.
+// The related FAULT_TOLERANT_WRITE_LAST_WRITE_DATA GUID hob will be only built if
+// FTW last write was still in progress with SpareComplete set and DestinationComplete not set.
+// It means the target buffer has been backed up in spare block, then target block has been erased,
+// but the target buffer has not been writen in target block from spare block.
+//
+extern EFI_GUID gEdkiiFaultTolerantWriteGuid;
+
+#endif