Re: [edk2] [PATCH 1/2] MdeModulePkg/Tcp4Dxe: Fix unconditional window shrinking

[Tian, Feng]

Adding network module owners for further review.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
ate...@kraftway.ru
Sent: Tuesday, March 28, 2017 3:20 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 1/2] MdeModulePkg/Tcp4Dxe: Fix unconditional window 
shrinking

Moving Right window edge to the left on sender side without additional checks 
leads to the situation when sender assumes the receiver shrunk its rcv buffer, 
when, in fact, it only reduced window size. This is a TCP deadlock situation. 
Receiver ACKs proper segment, while sender discards it for future ACK. Add 
check for negative usable window to prevent erroneous window shrinking.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrey Tepin 
---
 MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c 
b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c
index 1000538..ea0766a 100644
--- a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c
+++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c
@@ -703,6 +703,7 @@ TcpInput (
   TCP_SEG *Seg;
   TCP_SEQNO   Right;
   TCP_SEQNO   Urg;
+  INT32   UsableWnd;
 
   NET_CHECK_SIGNATURE (Nbuf, NET_BUF_SIGNATURE);
 
@@ -1188,7 +1189,10 @@ TcpInput (
 
   if (TCP_SEQ_LT (Right, Tcb->SndNxt)) {
 
-Tcb->SndNxt = Right;
+UsableWnd = Tcb->SndUna + Tcb->SndWnd - Tcb->SndNxt;
+if (UsableWnd < 0) {
+  Tcb->SndNxt = Right;
+}
 
 if (Right == Tcb->SndUna) {
 
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/12] OvmfPkg: Enable variable access in PEI

[Jordan Justen]

On 2017-03-28 02:22:37, Laszlo Ersek wrote:
> 
> > InstallProtocolInterface: [EfiLoadedImageProtocol] 7E9EEC10
> > SmmInstallProtocolInterface: [EfiLoadedImageProtocol] 7FFDD47C
> > Loading SMM driver at 0x0007FF5F000 EntryPoint=0x0007FF60034 
> > FvbServicesSmm.efi
> > ASSERT .../OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c(970): 
> > !_gPcd_FixedAtBuild_PcdSmmSmramRequire
> 
> The reason for the failed flash detection, in PlatformPei, is that
> PlatformPei does not run in System Management Mode. Therefore QEMU
> denies it write access to the pflash chip.

Ah. Yet another discrepancy from hardware. Anyway, I installed GCC
5.4, and I can now build IA32 again and reproduce the SMM issue. (GCC
6.3 is generating some unsupported relocations for me in the OVMF SEC
image.)

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg/setvar: Support data format in Shell 2.2 spec

[Ruiyu Ni]

From: Chen A Chen 

Shell 2.2 spec defines =0x/=0X, =H/=h, =S, =L and =P for
hex number, hex array, ascii string, unicode string and
device path data.
The patch adds such support.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen 
Cc: Ruiyu Ni 
Cc: Michael D Kinney 
Cc: Jaben Carsey 
Cc: Jeff Fan 
---
 .../Library/UefiShellDebug1CommandsLib/SetVar.c| 423 +++--
 1 file changed, 297 insertions(+), 126 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
index c59032a..fc76b58 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
@@ -1,4 +1,4 @@
-/** @file
+/** @file
   Main file for SetVar shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
@@ -23,6 +23,21 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
   {NULL, TypeMax}
   };
 
+typedef enum {
+  DataTypeHexNumber   = 0,
+  DataTypeHexArray= 1,
+  DataTypeAscii   = 2,
+  DataTypeUnicode = 3,
+  DataTypeDevicePath  = 4,
+  DataTypeUnKnow  = 5
+} DATA_TYPE;
+
+typedef union {
+  UINT8 HexNumber8;
+  UINT16HexNumber16;
+  UINT32HexNumber32;
+  UINT64HexNumber64;
+} HEX_NUMBER;
 
 /**
   Check if the input is a (potentially empty) string of hexadecimal nibbles.
@@ -50,6 +65,270 @@ IsStringOfHexNibbles (
   return TRUE;
 }
 
+/**
+  Function to check the TYPE of Data.
+
+  @param[in]Data  The Data to be check.
+
+  @retval   DATA_TYPE The TYPE of Data.
+**/
+DATA_TYPE
+TestDataType (
+  IN CONST CHAR16  *Data
+  )
+{
+  if (Data[0] == L'0' && (Data[1] == L'x' || Data[1] == L'X')) {
+if (IsStringOfHexNibbles (Data+2) && StrLen (Data + 2) <= 16) {
+  return DataTypeHexNumber;
+} else {
+  return DataTypeUnKnow;
+}
+  } else if (Data[0] == L'H') {
+if (IsStringOfHexNibbles (Data + 1) && StrLen (Data + 1) % 2 == 0) {
+  return DataTypeHexArray;
+} else {
+  return DataTypeUnKnow;
+}
+  } else if (Data[0] == L'S') {
+return DataTypeAscii;
+  } else if (Data[0] == L'L') {
+return DataTypeUnicode;
+  } else if (Data[0] == L'P' || StrnCmp (Data, L"--", 2) == 0) {
+return DataTypeDevicePath;
+  }
+
+  if (IsStringOfHexNibbles (Data) && StrLen (Data) % 2 == 0) {
+return DataTypeHexArray;
+  }
+
+  return DataTypeAscii;
+}
+
+/**
+  Function to parse the Data by the type of Data, and save in the Buffer.
+
+  @param[in]  DataA pointer to a buffer to be parsed.
+  @param[out] Buffer  A pointer to a buffer to hold the return 
data.
+  @param[in,out]  BufferSize  On input, indicates the size of Buffer 
in bytes.
+  On output,indicates the size of data 
return in Buffer.
+  Or the size in bytes of the buffer 
needed to obtain.
+
+  @retval   EFI_INVALID_PARAMETER The Buffer or BufferSize is NULL.
+  @retval   EFI_BUFFER_TOO_SMALL  The Buffer is too small to hold the data.
+  @retval   EFI_OUT_OF_RESOURCES  A memory allcation failed.
+  @retval   EFI_SUCCESS   The Data parsed successful and save in 
the Buffer.
+**/
+EFI_STATUS
+ParseParameterData (
+  IN CONST CHAR16   *Data,
+  OUT VOID  *Buffer,
+  IN OUT UINTN  *BufferSize
+  )
+{
+  UINT64HexNumber;
+  UINTN HexNumberLen;
+  UINTN Size;
+  CHAR8 *AsciiBuffer;
+  DATA_TYPE DataType;
+  EFI_DEVICE_PATH_PROTOCOL  *DevPath;
+  EFI_STATUSStatus;
+
+  HexNumber = 0;
+  HexNumberLen  = 0;
+  Size  = 0;
+  AsciiBuffer   = NULL;
+  DevPath   = NULL;
+  Status= EFI_SUCCESS;
+
+  if (Data == NULL || BufferSize == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  DataType = TestDataType (Data);
+  if (DataType == DataTypeHexNumber) {
+//
+// hex number
+//
+StrHexToUint64S (Data + 2, NULL, &HexNumber);
+HexNumberLen = StrLen (Data + 2);
+if (HexNumberLen >= 1 && HexNumberLen <= 2) {
+  Size = 1;
+} else if (HexNumberLen >= 3 && HexNumberLen <= 4) {
+  Size = 2;
+} else if (HexNumberLen >= 5 && HexNumberLen <= 8) {
+  Size = 4;
+} else if (HexNumberLen >= 9 && HexNumberLen <= 16) {
+  Size = 8;
+}
+if (Buffer != NULL && *BufferSize >= Size) {
+  CopyMem(Buffer, (VOID *)&HexNumber, Size);
+} else {
+  Status = EFI_BUFFER_TOO_SMALL;
+}
+*BufferSize = Size;
+  } else if (DataType == DataTypeHexArray) {
+//
+// hex array
+//
+if (*Data == L'H') {
+  Data = Data + 1;
+}
+
+Size = StrLen (Data) / 2;
+if (Buffer != NULL && *BufferSize >= Size) {
+  StrHexToBytes(Data, StrLen  (Data), (UINT8 *)Buffer, Size);
+} else {
+  

[edk2] [PATCH 08/10] UefiCpuPkg/MtrrLib: Use a better algorithm to calculate MTRR

[Ruiyu Ni]

The new algorithm finds out the more optimal MTRR solution for
current memory type settings.
Compare against the original algorithm, the new one guarantees
to find the correct MTRR solution, but doesn't guarantee to
find the most optimal MTRR solution.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 1466 +-
 1 file changed, 906 insertions(+), 560 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index bcc2df5..34e6ad6 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -30,6 +30,7 @@
 #define OR_SEED  0x0101010101010101ull
 #define CLEAR_SEED   0xull
 
+#define MTRR_LIB_ASSERT_ALIGNED(B, L) ASSERT ((B & ~(L - 1)) == B);
 //
 // Context to save and restore when MTRRs are programmed
 //
@@ -38,6 +39,12 @@ typedef struct {
   BOOLEAN  InterruptState;
 } MTRR_CONTEXT;
 
+typedef struct {
+  UINT64 BaseAddress;
+  UINT64 Length;
+  MTRR_MEMORY_CACHE_TYPE Type;
+} MEMORY_RANGE;
+
 //
 // This table defines the offset, base and length of the fixed MTRRs
 //
@@ -642,361 +649,309 @@ MtrrGetMemoryAttributeInVariableMtrr (
);
 }
 
-
 /**
-  Checks overlap between given memory range and MTRRs.
-
-  @param[in]  FirmwareVariableMtrrCount  The number of variable MTRRs available
- to firmware.
-  @param[in]  Start  The start address of memory range.
-  @param[in]  EndThe end address of memory range.
-  @param[in]  VariableMtrr   The array to shadow variable MTRRs 
content
+  Return the least alignment of address.
 
-  @retval TRUE Overlap exists.
-  @retval FALSENo overlap.
+  @param AddressThe address to return the alignment.
+  @param Alignment0 The alignment to return when Address is 0.
 
+  @return The least alignment of the Address.
 **/
-BOOLEAN
-CheckMemoryAttributeOverlap (
-  IN UINTN FirmwareVariableMtrrCount,
-  IN PHYSICAL_ADDRESS  Start,
-  IN PHYSICAL_ADDRESS  End,
-  IN VARIABLE_MTRR *VariableMtrr
-  )
+UINT64
+MtrrLibLeastAlignment (
+  UINT64Address,
+  UINT64Alignment0
+)
 {
-  UINT32  Index;
-
-  for (Index = 0; Index < FirmwareVariableMtrrCount; Index++) {
-if (
- VariableMtrr[Index].Valid &&
- !(
-   (Start > (VariableMtrr[Index].BaseAddress +
- VariableMtrr[Index].Length - 1)
-   ) ||
-   (End < VariableMtrr[Index].BaseAddress)
- )
-   ) {
-  return TRUE;
-}
+  if (Address == 0) {
+return Alignment0;
   }
 
-  return FALSE;
-}
-
-
-/**
-  Marks a variable MTRR as non-valid.
-
-  @param[in]   Index The index of the array VariableMtrr to be 
invalidated
-  @param[in]   VariableMtrr  The array to shadow variable MTRRs content
-  @param[out]  UsedMtrr  The number of MTRRs which has already been used
-
-**/
-VOID
-InvalidateShadowMtrr (
-  IN   UINTN  Index,
-  IN   VARIABLE_MTRR  *VariableMtrr,
-  OUT  UINT32 *UsedMtrr
-  )
-{
-  VariableMtrr[Index].Valid = FALSE;
-  *UsedMtrr = *UsedMtrr - 1;
+  return LShiftU64 (1, (UINTN) LowBitSet64 (Address));
 }
 
-
 /**
-  Combines memory attributes.
+  Return the number of required variable MTRRs to positively cover the
+  specified range.
 
-  If overlap exists between given memory range and MTRRs, try to combine them.
-
-  @param[in]   FirmwareVariableMtrrCount  The number of variable MTRRs
-  available to firmware.
-  @param[in]   Attributes The memory type to set.
-  @param[in, out]  Base   The base address of memory range.
-  @param[in, out]  Length The length of memory range.
-  @param[in]   VariableMtrr   The array to shadow variable 
MTRRs content
-  @param[in, out]  UsedMtrr   The number of MTRRs which has 
already been used
-  @param[out]  OverwriteExistingMtrr  Returns whether an existing MTRR 
was used
-
-  @retval EFI_SUCCESSMemory region successfully combined.
-  @retval EFI_ACCESS_DENIED  Memory region cannot be combined.
+  @param BaseAddress Base address of the range.
+  @param Length  Length of the range.
+  @param Alignment0  Alignment of 0.
 
+  @return The number of the required variable MTRRs.
 **/
-RETURN_STATUS
-CombineMemoryAttribute (
-  IN UINT32 FirmwareVariableMtrrCount,
-  IN UINT64 Attributes,
-  IN OUT UINT64 *Base,
-  IN OUT UINT64 *Length,
-  IN VARIABLE_MTRR  *VariableMtrr,
-  IN OUT UINT32 *UsedMtrr,
-  OUTBOOLEAN*OverwriteExistingMtrr
-  )
+UINT32
+MtrrLibGetPositiveMtrrNumber (
+  IN UINT64  BaseAddress,
+  IN UINT6

[edk2] [PATCH 10/10] UefiCpuPkg/MtrrLib: All functions use definitions in Msr.h

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 55 +---
 1 file changed, 33 insertions(+), 22 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 920cc5f..b7af838 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -50,57 +50,57 @@ typedef struct {
 //
 CONST FIXED_MTRR  mMtrrLibFixedMtrrTable[] = {
   {
-MTRR_LIB_IA32_MTRR_FIX64K_0,
+MSR_IA32_MTRR_FIX64K_0,
 0,
 SIZE_64KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX16K_8,
+MSR_IA32_MTRR_FIX16K_8,
 0x8,
 SIZE_16KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX16K_A,
+MSR_IA32_MTRR_FIX16K_A,
 0xA,
 SIZE_16KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_C,
+MSR_IA32_MTRR_FIX4K_C,
 0xC,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_C8000,
+MSR_IA32_MTRR_FIX4K_C8000,
 0xC8000,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_D,
+MSR_IA32_MTRR_FIX4K_D,
 0xD,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_D8000,
+MSR_IA32_MTRR_FIX4K_D8000,
 0xD8000,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_E,
+MSR_IA32_MTRR_FIX4K_E,
 0xE,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_E8000,
+MSR_IA32_MTRR_FIX4K_E8000,
 0xE8000,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_F,
+MSR_IA32_MTRR_FIX4K_F,
 0xF,
 SIZE_4KB
   },
   {
-MTRR_LIB_IA32_MTRR_FIX4K_F8000,
+MSR_IA32_MTRR_FIX4K_F8000,
 0xF8000,
 SIZE_4KB
   }
@@ -214,11 +214,15 @@ MtrrGetDefaultMemoryTypeWorker (
   IN MTRR_SETTINGS  *MtrrSetting
   )
 {
+  MSR_IA32_MTRR_DEF_TYPE_REGISTER DefType;
+
   if (MtrrSetting == NULL) {
-return (MTRR_MEMORY_CACHE_TYPE) (AsmReadMsr64 
(MTRR_LIB_IA32_MTRR_DEF_TYPE) & 0x7);
+DefType.Uint64 = AsmReadMsr64 (MSR_IA32_MTRR_DEF_TYPE);
   } else {
-return (MTRR_MEMORY_CACHE_TYPE) (MtrrSetting->MtrrDefType & 0x7);
+DefType.Uint64 = MtrrSetting->MtrrDefType;
   }
+
+  return (MTRR_MEMORY_CACHE_TYPE) DefType.Bits.Type;
 }
 
 
@@ -254,6 +258,7 @@ MtrrLibPreMtrrChange (
   OUT MTRR_CONTEXT  *MtrrContext
   )
 {
+  MSR_IA32_MTRR_DEF_TYPE_REGISTER  DefType;
   //
   // Disable interrupts and save current interrupt state
   //
@@ -278,7 +283,9 @@ MtrrLibPreMtrrChange (
   //
   // Disable MTRRs
   //
-  AsmMsrBitFieldWrite64 (MTRR_LIB_IA32_MTRR_DEF_TYPE, 10, 11, 0);
+  DefType.Uint64 = AsmReadMsr64 (MSR_IA32_MTRR_DEF_TYPE);
+  DefType.Bits.E = 0;
+  AsmWriteMsr64 (MSR_IA32_MTRR_DEF_TYPE, DefType.Uint64);
 }
 
 /**
@@ -330,10 +337,14 @@ MtrrLibPostMtrrChange (
   IN MTRR_CONTEXT  *MtrrContext
   )
 {
+  MSR_IA32_MTRR_DEF_TYPE_REGISTER  DefType;
   //
   // Enable Cache MTRR
   //
-  AsmMsrBitFieldWrite64 (MTRR_LIB_IA32_MTRR_DEF_TYPE, 10, 11, 3);
+  DefType.Uint64 = AsmReadMsr64 (MSR_IA32_MTRR_DEF_TYPE);
+  DefType.Bits.E = 1;
+  DefType.Bits.FE = 1;
+  AsmWriteMsr64 (MSR_IA32_MTRR_DEF_TYPE, DefType.Uint64);
 
   MtrrLibPostMtrrChangeEnableCache (MtrrContext);
 }
@@ -412,9 +423,9 @@ MtrrGetVariableMtrrWorker (
   for (Index = 0; Index < VariableMtrrCount; Index++) {
 if (MtrrSetting == NULL) {
   VariableSettings->Mtrr[Index].Base =
-AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1));
+AsmReadMsr64 (MSR_IA32_MTRR_PHYSBASE0 + (Index << 1));
   VariableSettings->Mtrr[Index].Mask =
-AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1) + 1);
+AsmReadMsr64 (MSR_IA32_MTRR_PHYSMASK0 + (Index << 1));
 } else {
   VariableSettings->Mtrr[Index].Base = 
MtrrSetting->Variables.Mtrr[Index].Base;
   VariableSettings->Mtrr[Index].Mask = 
MtrrSetting->Variables.Mtrr[Index].Mask;
@@ -591,7 +602,7 @@ MtrrGetMemoryAttributeInVariableMtrrWorker (
 
   ZeroMem (VariableMtrr, sizeof (VARIABLE_MTRR) * 
MTRR_NUMBER_OF_VARIABLE_MTRR);
   for (Index = 0, UsedMtrr = 0; Index < VariableMtrrCount; Index++) {
-if ((VariableSettings->Mtrr[Index].Mask & MTRR_LIB_CACHE_MTRR_ENABLED) != 
0) {
+if (((MSR_IA32_MTRR_PHYSMASK_REGISTER *) 
&VariableSettings->Mtrr[Index].Mask)->Bits.V != 0) {
   VariableMtrr[Index].Msr = (UINT32)Index;
   VariableMtrr[Index].BaseAddress = (VariableSettings->Mtrr[Index].Base & 
MtrrValidAddressMask);
   VariableMtrr[Index].Length  = ((~(VariableSettings->Mtrr[Index].Mask 
& MtrrValidAddressMask)) & MtrrValidBitsMask) + 1;
@@ -2206,11 +2217,11 @@ MtrrSetVariableMtrrWorker (
 
   for (Index = 0; Index < VariableMtrrCount; Index++) {
 AsmWriteMsr64 (
-  MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1),
+  MSR_IA32_MTRR_PHYSBASE0 + (Index << 1),
   VariableSettings->Mtrr[Index].Base
   );
 AsmWriteMsr64 (
-  MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1) + 1,
+  MSR_IA32_MTRR_PHYSMASK0 + (Index << 1),
  

[edk2] [PATCH 00/10] Use a better algorithm to calculate MTRR

[Ruiyu Ni]

The new algorithm finds out the more optimal MTRR solution for
current memory type settings.
Compare against the original algorithm, the new one guarantees
to find the correct MTRR solution, but doesn't guarantee to
find the most optimal MTRR solution.

Ruiyu Ni (10):
  UefiCpuPkg/MtrrLib: Correct typo in comments and remove TABs
  UefiCpuPkg/MtrrLib: Add CacheInvalid enum type to MtrrLib.h
  UefiCpuPkg/MtrrLib: IsMtrrSupported uses definitions in Msr.h
  UefiCpuPkg/MtrrLib: GetVariableMtrrCountWorker uses definitions in
Msr.h
  UefiCpuPkg/MtrrLib: Add MtrrLib prefix to ProgramFixedMtrr
  UefiCpuPkg/MtrrLib: Add MtrrLib prefix to several internal functions
  UefiCpuPkg/MtrrLib: MtrrLibInitializeMtrrMask() uses definitions in
CpuId.h
  UefiCpuPkg/MtrrLib: Use a better algorithm to calculate MTRR
  UefiCpuPkg/MtrrLib: Refine MtrrGetMemoryAttributeByAddressWorker
  UefiCpuPkg/MtrrLib: All functions use definitions in Msr.h

 UefiCpuPkg/Include/Library/MtrrLib.h |   17 +-
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 1838 --
 2 files changed, 1068 insertions(+), 787 deletions(-)

-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 09/10] UefiCpuPkg/MtrrLib: Refine MtrrGetMemoryAttributeByAddressWorker

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 237 ---
 1 file changed, 80 insertions(+), 157 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 34e6ad6..920cc5f 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -568,20 +568,19 @@ MtrrLibProgramFixedMtrr (
   This function shadows the content of variable MTRRs into an
   internal array: VariableMtrr.
 
-  @param[in]   VariableSettings   The variable MTRR values to shadow
-  @param[in]   FirmwareVariableMtrrCount  The number of variable MTRRs 
available to firmware
-  @param[in]   MtrrValidBitsMask  The mask for the valid bit of the 
MTRR
-  @param[in]   MtrrValidAddressMask   The valid address mask for MTRR
-  @param[out]  VariableMtrr   The array to shadow variable MTRRs 
content
+  @param[in]   VariableSettings  The variable MTRR values to shadow
+  @param[in]   VariableMtrrCount The number of variable MTRRs
+  @param[in]   MtrrValidBitsMask The mask for the valid bit of the MTRR
+  @param[in]   MtrrValidAddressMask  The valid address mask for MTRR
+  @param[out]  VariableMtrr  The array to shadow variable MTRRs content
 
-  @return   The return value of this parameter indicates 
the
-number of MTRRs which has been used.
+  @return  Number of MTRRs which has been used.
 
 **/
 UINT32
 MtrrGetMemoryAttributeInVariableMtrrWorker (
   IN  MTRR_VARIABLE_SETTINGS  *VariableSettings,
-  IN  UINTN   FirmwareVariableMtrrCount,
+  IN  UINTN   VariableMtrrCount,
   IN  UINT64  MtrrValidBitsMask,
   IN  UINT64  MtrrValidAddressMask,
   OUT VARIABLE_MTRR   *VariableMtrr
@@ -591,7 +590,7 @@ MtrrGetMemoryAttributeInVariableMtrrWorker (
   UINT32  UsedMtrr;
 
   ZeroMem (VariableMtrr, sizeof (VARIABLE_MTRR) * 
MTRR_NUMBER_OF_VARIABLE_MTRR);
-  for (Index = 0, UsedMtrr = 0; Index < FirmwareVariableMtrrCount; Index++) {
+  for (Index = 0, UsedMtrr = 0; Index < VariableMtrrCount; Index++) {
 if ((VariableSettings->Mtrr[Index].Mask & MTRR_LIB_CACHE_MTRR_ENABLED) != 
0) {
   VariableMtrr[Index].Msr = (UINT32)Index;
   VariableMtrr[Index].BaseAddress = (VariableSettings->Mtrr[Index].Base & 
MtrrValidAddressMask);
@@ -724,8 +723,10 @@ MtrrLibGetPositiveMtrrNumber (
   Return whether the left MTRR type precedes the right MTRR type.
 
   The MTRR type precedence rules are:
-  1. UC precedes any other type
-  2. WT precedes WB
+1. UC precedes any other type
+2. WT precedes WB
+  For further details, please refer the IA32 Software Developer's Manual,
+  Volume 3, Section "MTRR Precedences".
 
   @param Left  The left MTRR type.
   @param Right The right MTRR type.
@@ -954,46 +955,6 @@ MtrrLibGetMtrrNumber (
   return LeastSubtractiveMtrrNumber + MiddleMtrrNumber + LeastRightMtrrNumber;
 }
 
-
-/**
-  Converts the Memory attribute value to MTRR_MEMORY_CACHE_TYPE.
-
-  If MtrrSetting is not NULL, gets the default memory attribute from input
-  MTRR settings buffer.
-  If MtrrSetting is NULL, gets the default memory attribute from MSR.
-
-  @param[in]  MtrrSettingA buffer holding all MTRRs content.
-  @param[in]  MtrrType   MTRR memory type
-
-  @return The enum item in MTRR_MEMORY_CACHE_TYPE
-
-**/
-MTRR_MEMORY_CACHE_TYPE
-GetMemoryCacheTypeFromMtrrType (
-  IN MTRR_SETTINGS *MtrrSetting,
-  IN UINT64MtrrType
-  )
-{
-  switch (MtrrType) {
-  case MTRR_CACHE_UNCACHEABLE:
-return CacheUncacheable;
-  case MTRR_CACHE_WRITE_COMBINING:
-return CacheWriteCombining;
-  case MTRR_CACHE_WRITE_THROUGH:
-return CacheWriteThrough;
-  case MTRR_CACHE_WRITE_PROTECTED:
-return CacheWriteProtected;
-  case MTRR_CACHE_WRITE_BACK:
-return CacheWriteBack;
-  default:
-//
-// MtrrType is MTRR_CACHE_INVALID_TYPE, that means
-// no MTRR covers the range
-//
-return MtrrGetDefaultMemoryTypeWorker (MtrrSetting);
-  }
-}
-
 /**
   Initializes the valid bits mask and valid address mask for MTRRs.
 
@@ -1030,71 +991,34 @@ MtrrLibInitializeMtrrMask (
   Determines the real attribute of a memory range.
 
   This function is to arbitrate the real attribute of the memory when
-  there are 2 MTRRs covers the same memory range.  For further details,
+  there are 2 MTRRs covers the same memory range. For further details,
   please refer the IA32 Software Developer's Manual, Volume 3,
-  Section 10.11.4.1.
+  Section "MTRR Precedences".
 
   @param[in]  MtrrType1The first kind of Memory type
   @param[in]  MtrrType2The second kind of memory type
 
 **/
-UINT64
+MTRR_MEMORY_CACHE_TYPE
 MtrrLibPrecedence (
-  IN UINT64MtrrType1,
-  IN UINT64MtrrType2
+  IN MTRR_MEMORY_CACHE_TYPEMtrrType1,
+

[edk2] [PATCH 07/10] UefiCpuPkg/MtrrLib: MtrrLibInitializeMtrrMask() uses definitions in CpuId.h

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index d7e6f05..bcc2df5 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -1054,22 +1054,20 @@ MtrrLibInitializeMtrrMask (
   OUT UINT64 *MtrrValidAddressMask
   )
 {
-  UINT32  RegEax;
-  UINT8   PhysicalAddressBits;
+  UINT32  MaxExtendedFunction;
+  CPUID_VIR_PHY_ADDRESS_SIZE_EAX  VirPhyAddressSize;
 
-  AsmCpuid (0x8000, &RegEax, NULL, NULL, NULL);
 
-  if (RegEax >= 0x8008) {
-AsmCpuid (0x8008, &RegEax, NULL, NULL, NULL);
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, &MaxExtendedFunction, NULL, NULL, NULL);
 
-PhysicalAddressBits = (UINT8) RegEax;
-
-*MtrrValidBitsMask= LShiftU64 (1, PhysicalAddressBits) - 1;
-*MtrrValidAddressMask = *MtrrValidBitsMask & 0xf000ULL;
+  if (MaxExtendedFunction >= CPUID_VIR_PHY_ADDRESS_SIZE) {
+AsmCpuid (CPUID_VIR_PHY_ADDRESS_SIZE, &VirPhyAddressSize.Uint32, NULL, 
NULL, NULL);
   } else {
-*MtrrValidBitsMask= MTRR_LIB_MSR_VALID_MASK;
-*MtrrValidAddressMask = MTRR_LIB_CACHE_VALID_ADDRESS;
+VirPhyAddressSize.Bits.PhysicalAddressBits = 36;
   }
+
+  *MtrrValidBitsMask = LShiftU64 (1, 
VirPhyAddressSize.Bits.PhysicalAddressBits) - 1;
+  *MtrrValidAddressMask = *MtrrValidBitsMask & 0xf000ULL;
 }
 
 
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 05/10] UefiCpuPkg/MtrrLib: Add MtrrLib prefix to ProgramFixedMtrr

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 7e8a19a..4adc41f 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -445,7 +445,7 @@ MtrrGetVariableMtrr (
 /**
   Programs fixed MTRRs registers.
 
-  @param[in]  MemoryCacheType  The memory type to set.
+  @param[in]  Type The memory type to set.
   @param[in, out] Base The base address of memory range.
   @param[in, out] Length   The length of memory range.
   @param[in, out] LastMsrNum   On input, the last index of the fixed MTRR 
MSR to program.
@@ -459,13 +459,13 @@ MtrrGetVariableMtrr (
 
 **/
 RETURN_STATUS
-ProgramFixedMtrr (
-  IN UINT64   MemoryCacheType,
-  IN OUT UINT64   *Base,
-  IN OUT UINT64   *Length,
-  IN OUT UINT32   *LastMsrNum,
-  OUTUINT64   *ReturnClearMask,
-  OUTUINT64   *ReturnOrMask
+MtrrLibProgramFixedMtrr (
+  IN MTRR_MEMORY_CACHE_TYPE  Type,
+  IN OUT UINT64  *Base,
+  IN OUT UINT64  *Length,
+  IN OUT UINT32  *LastMsrNum,
+  OUTUINT64  *ReturnClearMask,
+  OUTUINT64  *ReturnOrMask
   )
 {
   UINT32  MsrNum;
@@ -491,7 +491,7 @@ ProgramFixedMtrr (
 }
   }
 
-  if (MsrNum >= MTRR_NUMBER_OF_FIXED_MTRR) {
+  if (MsrNum == MTRR_NUMBER_OF_FIXED_MTRR) {
 return RETURN_UNSUPPORTED;
   }
 
@@ -526,7 +526,7 @@ ProgramFixedMtrr (
   }
 
   ClearMask = CLEAR_SEED;
-  OrMask= MultU64x32 (OR_SEED, (UINT32)MemoryCacheType);
+  OrMask= MultU64x32 (OR_SEED, (UINT32) Type);
 
   if (LeftByteShift != 0) {
 //
@@ -1562,7 +1562,7 @@ MtrrSetMemoryAttributeWorker (
   if (BaseAddress < BASE_1MB) {
 MsrNum = (UINT32)-1;
 while ((BaseAddress < BASE_1MB) && (Length > 0) && Status == 
RETURN_SUCCESS) {
-  Status = ProgramFixedMtrr (MemoryType, &BaseAddress, &Length, &MsrNum, 
&ClearMask, &OrMask);
+  Status = MtrrLibProgramFixedMtrr (Attribute, &BaseAddress, &Length, 
&MsrNum, &ClearMask, &OrMask);
   if (RETURN_ERROR (Status)) {
 goto Done;
   }
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 06/10] UefiCpuPkg/MtrrLib: Add MtrrLib prefix to several internal functions

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 4adc41f..d7e6f05 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -243,7 +243,7 @@ MtrrGetDefaultMemoryType (
 
 **/
 VOID
-PreMtrrChange (
+MtrrLibPreMtrrChange (
   OUT MTRR_CONTEXT  *MtrrContext
   )
 {
@@ -284,7 +284,7 @@ PreMtrrChange (
 
 **/
 VOID
-PostMtrrChangeEnableCache (
+MtrrLibPostMtrrChangeEnableCache (
   IN MTRR_CONTEXT  *MtrrContext
   )
 {
@@ -319,7 +319,7 @@ PostMtrrChangeEnableCache (
 
 **/
 VOID
-PostMtrrChange (
+MtrrLibPostMtrrChange (
   IN MTRR_CONTEXT  *MtrrContext
   )
 {
@@ -328,7 +328,7 @@ PostMtrrChange (
   //
   AsmMsrBitFieldWrite64 (MTRR_LIB_IA32_MTRR_DEF_TYPE, 10, 11, 3);
 
-  PostMtrrChangeEnableCache (MtrrContext);
+  MtrrLibPostMtrrChangeEnableCache (MtrrContext);
 }
 
 /**
@@ -1086,7 +1086,7 @@ MtrrLibInitializeMtrrMask (
 
 **/
 UINT64
-MtrrPrecedence (
+MtrrLibPrecedence (
   IN UINT64MtrrType1,
   IN UINT64MtrrType2
   )
@@ -1245,7 +1245,7 @@ MtrrGetMemoryAttributeByAddressWorker (
   if (Address >= VariableMtrr[Index].BaseAddress &&
   Address < 
VariableMtrr[Index].BaseAddress+VariableMtrr[Index].Length) {
 TempMtrrType = VariableMtrr[Index].Type;
-MtrrType = MtrrPrecedence (MtrrType, TempMtrrType);
+MtrrType = MtrrLibPrecedence (MtrrType, TempMtrrType);
   }
 }
   }
@@ -1791,7 +1791,7 @@ Done:
   for (Index = 0; Index < MTRR_NUMBER_OF_FIXED_MTRR; Index++) {
 if (FixedSettingsModified[Index]) {
   if (!MtrrContextValid) {
-PreMtrrChange (&MtrrContext);
+MtrrLibPreMtrrChange (&MtrrContext);
 MtrrContextValid = TRUE;
   }
   AsmWriteMsr64 (
@@ -1809,7 +1809,7 @@ Done:
   if (WorkingVariableSettings.Mtrr[Index].Base != 
OriginalVariableSettings.Mtrr[Index].Base ||
   WorkingVariableSettings.Mtrr[Index].Mask != 
OriginalVariableSettings.Mtrr[Index].Mask) {
 if (!MtrrContextValid) {
-  PreMtrrChange (&MtrrContext);
+  MtrrLibPreMtrrChange (&MtrrContext);
   MtrrContextValid = TRUE;
 }
 AsmWriteMsr64 (
@@ -1824,7 +1824,7 @@ Done:
 }
   }
   if (MtrrContextValid) {
-PostMtrrChange (&MtrrContext);
+MtrrLibPostMtrrChange (&MtrrContext);
   }
 
   DEBUG((DEBUG_CACHE, "  Status = %r\n", Status));
@@ -1971,9 +1971,9 @@ MtrrSetVariableMtrr (
 return VariableSettings;
   }
 
-  PreMtrrChange (&MtrrContext);
+  MtrrLibPreMtrrChange (&MtrrContext);
   MtrrSetVariableMtrrWorker (VariableSettings);
-  PostMtrrChange (&MtrrContext);
+  MtrrLibPostMtrrChange (&MtrrContext);
   MtrrDebugPrintAllMtrrs ();
 
   return  VariableSettings;
@@ -2021,9 +2021,9 @@ MtrrSetFixedMtrr (
 return FixedSettings;
   }
 
-  PreMtrrChange (&MtrrContext);
+  MtrrLibPreMtrrChange (&MtrrContext);
   MtrrSetFixedMtrrWorker (FixedSettings);
-  PostMtrrChange (&MtrrContext);
+  MtrrLibPostMtrrChange (&MtrrContext);
   MtrrDebugPrintAllMtrrs ();
 
   return FixedSettings;
@@ -2091,7 +2091,7 @@ MtrrSetAllMtrrs (
 return MtrrSetting;
   }
 
-  PreMtrrChange (&MtrrContext);
+  MtrrLibPreMtrrChange (&MtrrContext);
 
   //
   // Set fixed MTRRs
@@ -2108,7 +2108,7 @@ MtrrSetAllMtrrs (
   //
   AsmWriteMsr64 (MTRR_LIB_IA32_MTRR_DEF_TYPE, MtrrSetting->MtrrDefType);
 
-  PostMtrrChangeEnableCache (&MtrrContext);
+  MtrrLibPostMtrrChangeEnableCache (&MtrrContext);
 
   return MtrrSetting;
 }
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 01/10] UefiCpuPkg/MtrrLib: Correct typo in comments and remove TABs

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Include/Library/MtrrLib.h | 14 +++---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c |  4 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h 
b/UefiCpuPkg/Include/Library/MtrrLib.h
index 4973d84..a769279 100644
--- a/UefiCpuPkg/Include/Library/MtrrLib.h
+++ b/UefiCpuPkg/Include/Library/MtrrLib.h
@@ -1,7 +1,7 @@
 /** @file
   MTRR setting library
 
-  Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -16,7 +16,7 @@
 #define  _MTRR_LIB_H_
 
 //
-// According to IA32 SDM, MTRRs number and msr offset are always consistent
+// According to IA32 SDM, MTRRs number and MSR offset are always consistent
 // for IA32 processor family
 //
 
@@ -92,11 +92,11 @@ typedef struct _MTRR_VARIABLE_SETTING_ {
 // Array for variable MTRRs
 //
 typedef struct _MTRR_VARIABLE_SETTINGS_ {
-   MTRR_VARIABLE_SETTING   Mtrr[MTRR_NUMBER_OF_VARIABLE_MTRR];
-}  MTRR_VARIABLE_SETTINGS;
+  MTRR_VARIABLE_SETTING   Mtrr[MTRR_NUMBER_OF_VARIABLE_MTRR];
+} MTRR_VARIABLE_SETTINGS;
 
 //
-// Array for fixed mtrrs
+// Array for fixed MTRRs
 //
 typedef  struct  _MTRR_FIXED_SETTINGS_ {
   UINT64   Mtrr[MTRR_NUMBER_OF_FIXED_MTRR];
@@ -209,7 +209,7 @@ MtrrGetMemoryAttribute (
 
   @param[out]  VariableSettings   A buffer to hold variable MTRRs content.
 
-  @return The buffer point to MTRR_VARIABLE_SETTINGS in which holds the 
content of the variable mtrr
+  @return The buffer point to MTRR_VARIABLE_SETTINGS in which holds the 
content of the variable MTRR
 
 **/
 MTRR_VARIABLE_SETTINGS*
@@ -220,7 +220,7 @@ MtrrGetVariableMtrr (
 
 
 /**
-  This function sets fixed MTRRs
+  This function sets variable MTRRs
 
   @param[in]  VariableSettings   A buffer to hold variable MTRRs content.
 
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 7783b63..2647dda 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -786,7 +786,7 @@ CombineMemoryAttribute (
   continue;
 } else {
   //
-  // The cache type is different, but the range is convered by one MTRR
+  // The cache type is different, but the range is covered by one MTRR
   //
   if (VariableMtrr[Index].BaseAddress == *Base && MtrrEnd == EndAddress) {
 InvalidateShadowMtrr (Index, VariableMtrr, UsedMtrr);
@@ -1278,7 +1278,7 @@ MtrrGetMemoryAttribute (
 /**
   Worker function prints all MTRRs for debugging.
 
-  If MtrrSetting is not NULL, print MTRR settings from from input MTRR
+  If MtrrSetting is not NULL, print MTRR settings from input MTRR
   settings buffer.
   If MtrrSetting is NULL, print MTRR settings from MTRRs.
 
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 02/10] UefiCpuPkg/MtrrLib: Add CacheInvalid enum type to MtrrLib.h

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Include/Library/MtrrLib.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h 
b/UefiCpuPkg/Include/Library/MtrrLib.h
index a769279..573c14c 100644
--- a/UefiCpuPkg/Include/Library/MtrrLib.h
+++ b/UefiCpuPkg/Include/Library/MtrrLib.h
@@ -119,7 +119,8 @@ typedef enum {
   CacheWriteCombining = 1,
   CacheWriteThrough   = 4,
   CacheWriteProtected = 5,
-  CacheWriteBack  = 6
+  CacheWriteBack  = 6,
+  CacheInvalid= 7
 } MTRR_MEMORY_CACHE_TYPE;
 
 #define  MTRR_CACHE_UNCACHEABLE  0
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 04/10] UefiCpuPkg/MtrrLib: GetVariableMtrrCountWorker uses definitions in Msr.h

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 38083d4..7e8a19a 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -124,11 +124,11 @@ GetVariableMtrrCountWorker (
   VOID
   )
 {
-  UINT32  VariableMtrrCount;
+  MSR_IA32_MTRRCAP_REGISTER MtrrCap;
 
-  VariableMtrrCount = (UINT32)(AsmReadMsr64 (MTRR_LIB_IA32_MTRR_CAP) & 
MTRR_LIB_IA32_MTRR_CAP_VCNT_MASK);
-  ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
-  return VariableMtrrCount;
+  MtrrCap.Uint64 = AsmReadMsr64 (MSR_IA32_MTRRCAP);
+  ASSERT (MtrrCap.Bits.VCNT <= MTRR_NUMBER_OF_VARIABLE_MTRR);
+  return MtrrCap.Bits.VCNT;
 }
 
 /**
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 03/10] UefiCpuPkg/MtrrLib: IsMtrrSupported uses definitions in Msr.h

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 2647dda..38083d4 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -18,6 +18,9 @@
 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -2124,26 +2127,25 @@ IsMtrrSupported (
   VOID
   )
 {
-  UINT32  RegEdx;
-  UINT64  MtrrCap;
+  CPUID_VERSION_INFO_EDXEdx;
+  MSR_IA32_MTRRCAP_REGISTER MtrrCap;
 
   //
   // Check CPUID(1).EDX[12] for MTRR capability
   //
-  AsmCpuid (1, NULL, NULL, NULL, &RegEdx);
-  if (BitFieldRead32 (RegEdx, 12, 12) == 0) {
+  AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, NULL, &Edx.Uint32);
+  if (Edx.Bits.MTRR == 0) {
 return FALSE;
   }
 
   //
-  // Check IA32_MTRRCAP.[0..7] for number of variable MTRRs and 
IA32_MTRRCAP[8] for
-  // fixed MTRRs existence. If number of variable MTRRs is zero, or fixed 
MTRRs do not
+  // Check number of variable MTRRs and fixed MTRRs existence.
+  // If number of variable MTRRs is zero, or fixed MTRRs do not
   // exist, return false.
   //
-  MtrrCap = AsmReadMsr64 (MTRR_LIB_IA32_MTRR_CAP);
-  if  ((BitFieldRead64 (MtrrCap, 0, 7) == 0) || (BitFieldRead64 (MtrrCap, 8, 
8) == 0)) {
+  MtrrCap.Uint64 = AsmReadMsr64 (MSR_IA32_MTRRCAP);
+  if ((MtrrCap.Bits.VCNT == 0) || (MtrrCap.Bits.FIX == 0)) {
 return FALSE;
   }
-
   return TRUE;
 }
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg/DxeHttpLib: Fix the incorrect return status if URI port is invalid

[Zhang, Lubo]

Reviewed-by: Zhang Lubo 

-Original Message-
From: Wu, Jiaxin 
Sent: Monday, March 27, 2017 2:48 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Lubo ; Ye, Ting ; Fu, 
Siyuan ; Wu, Jiaxin 
Subject: [Patch] MdeModulePkg/DxeHttpLib: Fix the incorrect return status if 
URI port is invalid

Cc: Zhang Lubo 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 15 +++  
MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.h |  5 -
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c 
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index 2ff04ff..8e29213 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -690,18 +690,22 @@ HttpUrlGetPort (
  OUT  UINT16 *Port
   )
 {
   CHAR8 *PortString;
   EFI_STATUSStatus;
+  UINTN Index;
   UINTN Data;
   UINT32ResultLength;
   HTTP_URL_PARSER  *Parser;
 
   if (Url == NULL || UrlParser == NULL || Port == NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
+  *Port = 0;
+  Index = 0;
+
   Parser = (HTTP_URL_PARSER*) UrlParser;
 
   if ((Parser->FieldBitMap & BIT (HTTP_URI_FIELD_PORT)) == 0) {
 return EFI_INVALID_PARAMETER;
   }
@@ -721,12 +725,23 @@ HttpUrlGetPort (
 return Status;
   }
 
   PortString[ResultLength] = '\0';
 
+  while (Index < ResultLength) {
+if (!NET_IS_DIGIT (PortString[Index])) {
+  return EFI_INVALID_PARAMETER;
+}
+Index ++;
+  }
+
   Status =  AsciiStrDecimalToUintnS (Url + 
Parser->FieldData[HTTP_URI_FIELD_PORT].Offset, (CHAR8 **) NULL, &Data);
 
+  if (Data > HTTP_URI_PORT_MAX_NUM || Data < HTTP_URI_PORT_MIN_NUM) {
+return EFI_INVALID_PARAMETER;
+  }
+
   *Port = (UINT16) Data;
   return Status;
 }
 
 /**
diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.h 
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.h
index 0d0ad3d..5ee0fdc 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.h
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.h
@@ -1,9 +1,9 @@
 /** @file
 Header file for HttpLib.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights 
+ reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -48,10 +48,13 @@ Header file for HttpLib.
 #define   HTTP_URI_FIELD_USERINFO 5
 #define   HTTP_URI_FIELD_HOST 6
 #define   HTTP_URI_FIELD_PORT 7
 #define   HTTP_URI_FIELD_MAX  8
 
+#define   HTTP_URI_PORT_MIN_NUM   0
+#define   HTTP_URI_PORT_MAX_NUM   65535
+
 //
 // Structure to store the parse result of a HTTP URL.
 //
 typedef struct {
   UINT32  Offset;
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Hypervisor with UEFI

[Blibbet]

> There are some web pages described Hypervisor with UEFI Firmware.  Are
there
> some Hypervisor sample implementations in current EDKII source code base?

Alex's SimpleVisor is a UEFI hypervisor.
https://firmwaresecurity.com/2016/08/31/alex-working-on-uefisor-simplevisor-for-uefi/
https://firmwaresecurity.com/2016/09/03/simplevisor-is-now-also-uefisor/
https://firmwaresecurity.com/2016/08/28/alexs-simplevisor-now-supports-ept-and-vpid/

Hope this helps.
Lee Fisher

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.

[Yao, Jiewen]

Agree. That is a good idea.

I will add that in V2 patch.

Thank you
Yao Jiewen

From: Kinney, Michael D
Sent: Wednesday, March 29, 2017 7:03 AM
To: Ard Biesheuvel ; Yao, Jiewen 
; Kinney, Michael D 
Cc: Ni, Ruiyu ; Leo Duran ; 
edk2-devel@lists.01.org; Brijesh Singh 
Subject: RE: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol 
definition.

Ard,

I agree.  And I think the IOMMU protocol should also support flexible
double buffer operations so the extra copies by the host CPU can be
avoided if the logical DMA address can directly map to the original
buffer.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, March 28, 2017 3:39 PM
> To: Yao, Jiewen mailto:jiewen@intel.com>>
> Cc: Ni, Ruiyu mailto:ruiyu...@intel.com>>; Leo Duran 
> mailto:leo.du...@amd.com>>; edk2-
> de...@lists.01.org; Brijesh Singh 
> mailto:brijesh.si...@amd.com>>
> Subject: Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol
> definition.
>
> On 25 March 2017 at 09:28, Jiewen Yao 
> mailto:jiewen@intel.com>> wrote:
> > This protocol is to abstract IOMMU access.
> >
> > Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> > Cc: Leo Duran mailto:leo.du...@amd.com>>
> > Cc: Brijesh Singh mailto:brijesh.si...@amd.com>>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiewen Yao 
> > mailto:jiewen@intel.com>>
>
> Hello all,
>
> It would be very useful for a IOMMU protocol such as this one to
> support non-identity mappings between the host and the PCI bus.
>
> On 64-bit ARM systems, no RAM may exist below 4 GB, and if a IOMMU is
> available, it could be used to remap RAM for DMA in a way that makes
> it 32-bit addressable for PCI masters that are not 64-bit capable.
>
> The PCI protocols in UEFI already allow such non-identity mappings. If
> a IOMMU protocol is introduced, it makes sense to allow it to be
> involved in establishing the device address when performing a map
> operation.
>
> --
> Ard.
>
>
> > ---
> >  MdeModulePkg/Include/Protocol/IoMmu.h | 132 
> >  MdeModulePkg/MdeModulePkg.dec |   3 +
> >  2 files changed, 135 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Protocol/IoMmu.h
> b/MdeModulePkg/Include/Protocol/IoMmu.h
> > new file mode 100644
> > index 000..55b9c78
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Protocol/IoMmu.h
> > @@ -0,0 +1,132 @@
> > +/** @file
> > +  EFI IOMMU Protocol.
> > +
> > +Copyright (c) 2017, Intel Corporation. All rights reserved.
> > +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 __IOMMU_H__
> > +#define __IOMMU_H__
> > +
> > +//
> > +// IOMMU Protocol GUID value
> > +//
> > +#define EDKII_IOMMU_PROTOCOL_GUID \
> > +{ \
> > +  0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 0xe1, 0xce, 0x51, 
> > 0x7c,
> 0x1e } \
> > +}
> > +
> > +//
> > +// Forward reference for pure ANSI compatability
> > +//
> > +typedef struct _EDKII_IOMMU_PROTOCOL  EDKII_IOMMU_PROTOCOL;
> > +
> > +//
> > +// Revision The revision to which the IOMMU interface adheres.
> > +//  All future revisions must be backwards compatible.
> > +//  If a future version is not back wards compatible it is not the 
> > same
> GUID.
> > +//
> > +#define EDKII_IOMMU_PROTOCOL_REVISION 0x0001
> > +
> > +//
> > +// IOMMU attribute.
> > +// These types can be "ORed" together as needed.
> > +// Any undefined bits are reserved and must be zero.
> > +//
> > +#define EDKII_IOMMU_ATTRIBUTE_READ   0x1
> > +#define EDKII_IOMMU_ATTRIBUTE_WRITE  0x2
> > +
> > +/**
> > +  Set IOMMU attribute for a system memory.
> > +
> > +  If the IOMMU protocol exists, the system memory cannot be used
> > +  for DMA by default.
> > +
> > +  When a device requests a DMA access for a system memory,
> > +  the device driver need use SetAttribute() to update the IOMMU
> > +  attribute to request DMA access (read and/or write).
> > +
> > +  The DeviceHandle is used to identify which device it is.
> > +  The IOMMU implementation need translate the device path to an IOMMU 
> > device ID,
> > +  and set IOMMU hardware register accordingly.
> > +  1) DeviceHandle can be a standard PCI device.
> > + The memory for BusMasterRead need set EDKII_IOMMU_ATTRIBUTE_READ.
> > + The memory for BusMasterWrite need set EDKII_IOMMU_ATTRIBUTE_WRITE.
> > + The memory for BusMasterCommonBuffer need set
> EDKII_IOMMU_ATTRIBUTE_READ|EDKII_IOMMU_ATTRIBUTE_WRITE.
> > + After the memory is used, the memory need s

Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.

[Kinney, Michael D]

Ard,

I agree.  And I think the IOMMU protocol should also support flexible
double buffer operations so the extra copies by the host CPU can be
avoided if the logical DMA address can directly map to the original
buffer.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, March 28, 2017 3:39 PM
> To: Yao, Jiewen 
> Cc: Ni, Ruiyu ; Leo Duran ; edk2-
> de...@lists.01.org; Brijesh Singh 
> Subject: Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol
> definition.
> 
> On 25 March 2017 at 09:28, Jiewen Yao  wrote:
> > This protocol is to abstract IOMMU access.
> >
> > Cc: Ruiyu Ni 
> > Cc: Leo Duran 
> > Cc: Brijesh Singh 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiewen Yao 
> 
> Hello all,
> 
> It would be very useful for a IOMMU protocol such as this one to
> support non-identity mappings between the host and the PCI bus.
> 
> On 64-bit ARM systems, no RAM may exist below 4 GB, and if a IOMMU is
> available, it could be used to remap RAM for DMA in a way that makes
> it 32-bit addressable for PCI masters that are not 64-bit capable.
> 
> The PCI protocols in UEFI already allow such non-identity mappings. If
> a IOMMU protocol is introduced, it makes sense to allow it to be
> involved in establishing the device address when performing a map
> operation.
> 
> --
> Ard.
> 
> 
> > ---
> >  MdeModulePkg/Include/Protocol/IoMmu.h | 132 
> >  MdeModulePkg/MdeModulePkg.dec |   3 +
> >  2 files changed, 135 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Protocol/IoMmu.h
> b/MdeModulePkg/Include/Protocol/IoMmu.h
> > new file mode 100644
> > index 000..55b9c78
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Protocol/IoMmu.h
> > @@ -0,0 +1,132 @@
> > +/** @file
> > +  EFI IOMMU Protocol.
> > +
> > +Copyright (c) 2017, Intel Corporation. All rights reserved.
> > +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 __IOMMU_H__
> > +#define __IOMMU_H__
> > +
> > +//
> > +// IOMMU Protocol GUID value
> > +//
> > +#define EDKII_IOMMU_PROTOCOL_GUID \
> > +{ \
> > +  0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 0xe1, 0xce, 0x51, 
> > 0x7c,
> 0x1e } \
> > +}
> > +
> > +//
> > +// Forward reference for pure ANSI compatability
> > +//
> > +typedef struct _EDKII_IOMMU_PROTOCOL  EDKII_IOMMU_PROTOCOL;
> > +
> > +//
> > +// Revision The revision to which the IOMMU interface adheres.
> > +//  All future revisions must be backwards compatible.
> > +//  If a future version is not back wards compatible it is not the 
> > same
> GUID.
> > +//
> > +#define EDKII_IOMMU_PROTOCOL_REVISION 0x0001
> > +
> > +//
> > +// IOMMU attribute.
> > +// These types can be "ORed" together as needed.
> > +// Any undefined bits are reserved and must be zero.
> > +//
> > +#define EDKII_IOMMU_ATTRIBUTE_READ   0x1
> > +#define EDKII_IOMMU_ATTRIBUTE_WRITE  0x2
> > +
> > +/**
> > +  Set IOMMU attribute for a system memory.
> > +
> > +  If the IOMMU protocol exists, the system memory cannot be used
> > +  for DMA by default.
> > +
> > +  When a device requests a DMA access for a system memory,
> > +  the device driver need use SetAttribute() to update the IOMMU
> > +  attribute to request DMA access (read and/or write).
> > +
> > +  The DeviceHandle is used to identify which device it is.
> > +  The IOMMU implementation need translate the device path to an IOMMU 
> > device ID,
> > +  and set IOMMU hardware register accordingly.
> > +  1) DeviceHandle can be a standard PCI device.
> > + The memory for BusMasterRead need set EDKII_IOMMU_ATTRIBUTE_READ.
> > + The memory for BusMasterWrite need set EDKII_IOMMU_ATTRIBUTE_WRITE.
> > + The memory for BusMasterCommonBuffer need set
> EDKII_IOMMU_ATTRIBUTE_READ|EDKII_IOMMU_ATTRIBUTE_WRITE.
> > + After the memory is used, the memory need set 0 to keep it being 
> > protected.
> > +  2) DeviceHandle can be an ACPI device (ISA, I2C, SPI, etc).
> > + The memory for DMA access need set EDKII_IOMMU_ATTRIBUTE_READ and/or
> EDKII_IOMMU_ATTRIBUTE_WRITE.
> > +
> > +  @param  This  The protocol instance pointer.
> > +  @param  DeviceHandle  The device who initiates the DMA access 
> > request.
> > +  @param  BaseAddress   The base of system memory address to be used 
> > as the
> DMA memory.
> > +  @param  LengthThe length of system memory address to be used 
> > as
> the DMA memory.
> > +  @param  IoMmuAttributeThe IOMMU attribute.
> > +

Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.

[Ard Biesheuvel]

On 25 March 2017 at 09:28, Jiewen Yao  wrote:
> This protocol is to abstract IOMMU access.
>
> Cc: Ruiyu Ni 
> Cc: Leo Duran 
> Cc: Brijesh Singh 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 

Hello all,

It would be very useful for a IOMMU protocol such as this one to
support non-identity mappings between the host and the PCI bus.

On 64-bit ARM systems, no RAM may exist below 4 GB, and if a IOMMU is
available, it could be used to remap RAM for DMA in a way that makes
it 32-bit addressable for PCI masters that are not 64-bit capable.

The PCI protocols in UEFI already allow such non-identity mappings. If
a IOMMU protocol is introduced, it makes sense to allow it to be
involved in establishing the device address when performing a map
operation.

-- 
Ard.


> ---
>  MdeModulePkg/Include/Protocol/IoMmu.h | 132 
>  MdeModulePkg/MdeModulePkg.dec |   3 +
>  2 files changed, 135 insertions(+)
>
> diff --git a/MdeModulePkg/Include/Protocol/IoMmu.h 
> b/MdeModulePkg/Include/Protocol/IoMmu.h
> new file mode 100644
> index 000..55b9c78
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/IoMmu.h
> @@ -0,0 +1,132 @@
> +/** @file
> +  EFI IOMMU Protocol.
> +
> +Copyright (c) 2017, Intel Corporation. All rights reserved.
> +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 __IOMMU_H__
> +#define __IOMMU_H__
> +
> +//
> +// IOMMU Protocol GUID value
> +//
> +#define EDKII_IOMMU_PROTOCOL_GUID \
> +{ \
> +  0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 0xe1, 0xce, 0x51, 
> 0x7c, 0x1e } \
> +}
> +
> +//
> +// Forward reference for pure ANSI compatability
> +//
> +typedef struct _EDKII_IOMMU_PROTOCOL  EDKII_IOMMU_PROTOCOL;
> +
> +//
> +// Revision The revision to which the IOMMU interface adheres.
> +//  All future revisions must be backwards compatible.
> +//  If a future version is not back wards compatible it is not the 
> same GUID.
> +//
> +#define EDKII_IOMMU_PROTOCOL_REVISION 0x0001
> +
> +//
> +// IOMMU attribute.
> +// These types can be "ORed" together as needed.
> +// Any undefined bits are reserved and must be zero.
> +//
> +#define EDKII_IOMMU_ATTRIBUTE_READ   0x1
> +#define EDKII_IOMMU_ATTRIBUTE_WRITE  0x2
> +
> +/**
> +  Set IOMMU attribute for a system memory.
> +
> +  If the IOMMU protocol exists, the system memory cannot be used
> +  for DMA by default.
> +
> +  When a device requests a DMA access for a system memory,
> +  the device driver need use SetAttribute() to update the IOMMU
> +  attribute to request DMA access (read and/or write).
> +
> +  The DeviceHandle is used to identify which device it is.
> +  The IOMMU implementation need translate the device path to an IOMMU device 
> ID,
> +  and set IOMMU hardware register accordingly.
> +  1) DeviceHandle can be a standard PCI device.
> + The memory for BusMasterRead need set EDKII_IOMMU_ATTRIBUTE_READ.
> + The memory for BusMasterWrite need set EDKII_IOMMU_ATTRIBUTE_WRITE.
> + The memory for BusMasterCommonBuffer need set 
> EDKII_IOMMU_ATTRIBUTE_READ|EDKII_IOMMU_ATTRIBUTE_WRITE.
> + After the memory is used, the memory need set 0 to keep it being 
> protected.
> +  2) DeviceHandle can be an ACPI device (ISA, I2C, SPI, etc).
> + The memory for DMA access need set EDKII_IOMMU_ATTRIBUTE_READ and/or 
> EDKII_IOMMU_ATTRIBUTE_WRITE.
> +
> +  @param  This  The protocol instance pointer.
> +  @param  DeviceHandle  The device who initiates the DMA access request.
> +  @param  BaseAddress   The base of system memory address to be used as 
> the DMA memory.
> +  @param  LengthThe length of system memory address to be used 
> as the DMA memory.
> +  @param  IoMmuAttributeThe IOMMU attribute.
> +
> +  @retval EFI_SUCCESSThe IoMmuAttribute is set for the memory 
> range specified by BaseAddress and Length.
> +  @retval EFI_INVALID_PARAMETER  DeviceHandle is an invalid handle.
> +  @retval EFI_INVALID_PARAMETER  BaseAddress is not IoMmu Page size aligned.
> +  @retval EFI_INVALID_PARAMETER  Length is not IoMmu Page size aligned.
> +  @retval EFI_INVALID_PARAMETER  Length is 0.
> +  @retval EFI_INVALID_PARAMETER  IoMmuAttribute specified an illegal 
> combination of attributes.
> +  @retval EFI_UNSUPPORTEDDeviceHandle is unknown by the IOMMU.
> +  @retval EFI_UNSUPPORTEDThe bit mask of IoMmuAttribute is not 
> supported by the IOMMU.
> +  @retval EFI_UNSUPPORTEDThe IOMMU does not support the memory range 
> specified by BaseAddress and Length.
> +  @retval EFI_OUT_OF_

Re: [edk2] [edk2-staging][PATCH 2/2] ShellPkg: Add acpiview tool to dump ACPI tables

[Jeff Westfahl]

Hi Sami,

Just another note, acpiview doesn't currently build on Windows, at least 
not with Visual Studio 2015. This isn't a problem for me as I don't 
usually build the shell on Windows, I just happened to notice it.


Regards,

Jeff Westfahl

On Fri, 17 Mar 2017, Sami Mujawar wrote:


Hi Jeff,

Thank you for letting us know these issues. I will provide an update to fix 
this soon.

Regards,

Sami Mujawar

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff 
Westfahl
Sent: 16 March 2017 03:12
To: Evan Lloyd
Cc: Ruiyu Ni Leif Lindholm; edk2-de...@ml01.01.org; Jaben Carsey; Jiewen Yao; 
Michael D Kinney; linaro@ml01.01.org; Dong Wei
Subject: Re: [edk2] [edk2-staging][PATCH 2/2] ShellPkg: Add acpiview tool to 
dump ACPI tables

Hi Evan,

I really appreciate this work, I've missed this functionality in the EFI shell.

Just a few minor things that I noticed:

1. In AcpiView.c, you use '\t' in a few places. For some reason, on my Intel 
PC, these tabs are displayed as a reverse color '?'. I'm not sure where the 
fault lies here. It seems like tab characters should be pretty universally 
understood, but I also don't see any tab characters in other parts of the shell 
code that are printed to the console.

2. In MadtParser.c, the error message at line 270 needs a newline. (No, my 
Intel PC doesn't have a GIC :)

Regards,
Jeff

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
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.


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

On 28 March 2017 at 19:00, Laszlo Ersek  wrote:
> On 03/28/17 19:30, Ard Biesheuvel wrote:
>> On 28 March 2017 at 18:26, Laszlo Ersek  wrote:
>
> +#define DT_ACPI_VARIABLE_NAME   L"DtAcpiPref"
>
>>> Can you replace this instance of "... DtAcpiPref ..." with "... %a ..."
>>> and DT_ACPI_VARIABLE_NAME? No need to resubmit.
>>>
>>
>> That should be %s, I suppose?
>
> Heh, sure. Forgot the L by the time I got there :)
>


Pushed as 779cc439e881

Thanks,
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Laszlo Ersek]

On 03/28/17 19:30, Ard Biesheuvel wrote:
> On 28 March 2017 at 18:26, Laszlo Ersek  wrote:

 +#define DT_ACPI_VARIABLE_NAME   L"DtAcpiPref"

>> Can you replace this instance of "... DtAcpiPref ..." with "... %a ..."
>> and DT_ACPI_VARIABLE_NAME? No need to resubmit.
>>
> 
> That should be %s, I suppose?

Heh, sure. Forgot the L by the time I got there :)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v2] GitBook documentation process

[Kinney, Michael D]

Hello,

I have added draft versions of the EDK II DEC, INF, DSC, FDF, UNI,
and Template Specifications based on this RFC.  These are now hosted
in the Tianocore-docs organization on GitHub and the Tianocore-docs
organization on Gitbook.

  https://github.com/tianocore-docs
  https://www.gitbook.com/@edk2-docs

I have added an EDK II Draft Specifications Wiki page that contains
links to the published versions of these draft specifications from
Gitbook along with links to the Gitbook page and GitHub repository
for each specification.

  
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Draft-Specification

I want to make sure no content was lost in the conversion to Gitbook.
Please review these drafts and use either the Gitbook commenting feature
or Tianocore Bugzilla (https://bugzilla.tianocore.org) to provide feedback.

I will continue to convert the remaining EDK II related specifications.

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, March 22, 2017 9:14 PM
> To: edk2-devel@lists.01.org; Kinney, Michael D 
> Subject: [edk2][RFC v2] GitBook documentation process
> 
> Hello,
> 
> I have updated the GitBook RFC based on feedback received.
> 
> Changes for V2:
> ===
> * Remove [docs] from email subject
> * Update Bugzilla for document issues to remove Package
>   field and add Document field
> ===
> 
> The following is an RFC proposal for using GitBook for tianocore
> documentation.  This RFC is also available at the following link:
> 
> * https://github.com/mdkinney/edk2-TemplateSpecification/wiki
> 
> Please review this proposal and the referenced documents and
> provide any comments or concerns you may have.
> 
> The Sample GitBook documents are hosted in personal GitHub and
> personal GitBook pages.  When this RFC is approved, these will
> documents be migrated to Tianocore pages and additional EDK II
> related documents will be added as the conversion to GitBook
> format is completed.
> 
> I have added more EDK II documents since the first version of
> this RFC.  The complete set now available for review are:
> 
> * EDK II Template Specification
>   https://www.gitbook.com/book/mdkinney/edk-ii-template-specification
> 
> * EDK II DEC Specification
>   https://www.gitbook.com/book/mdkinney/edk-ii-dec-specification
> 
> * EDK II UNI Specification
>   https://www.gitbook.com/book/mdkinney/edk-ii-uni-specification
> 
> * EDK II FDF Specification
>   https://www.gitbook.com/book/mdkinney/edk-ii-fdf-specification
> 
> * EDK II DSC Specification
>   https://www.gitbook.com/book/mdkinney/edk-ii-dsc-specification
> 
> Thanks,
> 
> Mike
> 
> ===
> 
> [edk2][RFC v2] GitBook documentation process
> 
> # Introduction
> 
> This RFC provide a proposal to create and maintain open source documents
> associated with the Tianocore project.  Markdown is a document source format
> that is compatible with the patch review process that is currently used for
> EDK II source changes.  [GitBook](https://www.gitbook.com) is a document
> publishing service that uses Markdown as an input format and can generate
> published documents as web pages, PDF, MOBI, and EPUB and provide a GitHub
> integration service that supports pulling Markdown sources from GitHub hosted
> repositories.
> 
> There are several elements to this proposal:
> 
> * Update of the TianoCore Contribution Agreement from Version 1.0 to
>   Version 1.1 to cover open source documentation associated with the
>   TianoCore project.  The following is a link to the revised agreement.
> 
>   
> https://github.com/mdkinney/edk2-TemplateSpecification/blob/master/CONTRIBUTIONS.txt
> 
> * New license for TianoCore documentation source files and TianoCore published
>   documents.  The following is a link to the license that is based on the
>   [FreeBSD Documentation 
> License](https://www.freebsd.org/copyright/freebsd-doc-
> license.html):
> 
>   
> https://github.com/mdkinney/edk2-TemplateSpecification/blob/master/LICENSE.txt
> 
> * Use [TianoCore-Docs](https://github.com/tianocore-docs) GitHub organization 
> to
>   host the GIT repositories for TianoCore documents.  The reason a new 
> organization
>   is being used is because the GitBook services requires one GIT repository 
> per
>   document.  A separate organization separates the source code repositories 
> from
>   documentation repositories.
> 
> * Use [TianoCore Bugzilla](https://bugzilla.tianocore.org) to report document 
> issues.
> + Add DocumentName as a required setting when reporting a document issue
> + Remove PackageName as a required setting when reporting a document issue
> 
> * Use the same patch review process that is used for EDK II source code to 
> provide
>   changes to TianoCore documents with the differences listed below.  This is 
> a very
>   brief summary.  A second RFC and/or Wiki page will cover the detailed 
> process.
> 
>   1. Use `[repo-

Re: [edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

On 28 March 2017 at 18:26, Laszlo Ersek  wrote:
> On 03/28/17 18:16, Ard Biesheuvel wrote:
>> (use correct address for Marcin -- please take into account when replying)
>>
>> On 28 March 2017 at 17:15, Ard Biesheuvel  wrote:
>>> As a follow up to the changes proposed by Laszlo to make ACPI and DT
>>> mutually exclusive on ArmVirtQemu, this patch proposed a DT platform
>
> new typo relative to v1: s/proposed/proposes/
>
>>> DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
>>> or installs the FV embedded DTB binary as a configuration table under
>>> the appropriate GUID, depending on a preference setting recorded as
>>> a UEFI variable, and configurable via a HII screen.
>>>
>>> The DTB binary can be embedded in the firmware image by adding the
>>> following to the platform .fdf file:
>>>
>>>   FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
>>> SECTION RAW = SomePkg/path/to/foo.dtb
>>>   }
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>> v2: fixup various errors and rough edges pointed out by Laszlo
>>>
>>>  EmbeddedPkg/EmbeddedPkg.dec |   6 +
>>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  65 ++
>>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  31 +++
>>>  EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
>>>  EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
>>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  51 +
>>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 216 
>>> 
>>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
>>>  8 files changed, 442 insertions(+)
>>>
>>> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
>>> index 29736fb4a71d..871fc5ff4016 100644
>>> --- a/EmbeddedPkg/EmbeddedPkg.dec
>>> +++ b/EmbeddedPkg/EmbeddedPkg.dec
>>> @@ -62,6 +62,12 @@ [Guids.common]
>>>## Include/Guid/PlatformHasDeviceTree.h
>>>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
>>> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>>>
>>> +  # HII form set GUID for DtPlatformDxe driver
>>> +  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 
>>> 0xdf, 0xa4, 0x41, 0x5f, 0x55, 0x26 } }
>>> +
>>> +  # File GUID for default DTB image embedded in the firmware volume
>>> +  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 
>>> 0x1d, 0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
>>> +
>>>  [Protocols.common]
>>>gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
>>> 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
>>>gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 
>>> 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
>>> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf 
>>> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
>>> new file mode 100644
>>> index ..aa1d3abb4012
>>> --- /dev/null
>>> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
>>> @@ -0,0 +1,65 @@
>>> +## @file
>>> +#
>>> +#  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
>>> +#
>>> +#  This program and the accompanying materials are licensed and made
>>> +#  available under the terms and conditions of the BSD License which
>>> +#  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.
>>> +#
>>> +##
>>> +
>>> +[Defines]
>>> +  INF_VERSION   = 0x00010019
>>> +  BASE_NAME = DtPlatformDxe
>>> +  FILE_GUID = FC097B3C-2EBD-4A75-A3DA-121DCAB365CC
>>> +  MODULE_TYPE   = DXE_DRIVER
>>> +  VERSION_STRING= 1.0
>>> +  ENTRY_POINT   = DtPlatformDxeEntryPoint
>>> +
>>> +#
>>> +# The following information is for reference only and not required by the 
>>> build tools.
>>> +#
>>> +#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
>>> +#
>>> +
>>> +[Sources]
>>> +  DtPlatformDxe.c
>>> +  DtPlatformHii.vfr
>>> +  DtPlatformHii.uni
>>> +
>>> +[Packages]
>>> +  EmbeddedPkg/EmbeddedPkg.dec
>>> +  MdePkg/MdePkg.dec
>>> +  MdeModulePkg/MdeModulePkg.dec
>>> +
>>> +[LibraryClasses]
>>> +  BaseLib
>>> +  DebugLib
>>> +  UefiLib
>>> +  UefiDriverEntryPoint
>>> +  UefiBootServicesTableLib
>>> +  UefiRuntimeServicesTableLib
>>> +  UefiHiiServicesLib
>>> +  MemoryAllocationLib
>>> +  HiiLib
>>> +  PcdLib
>>> +  DxeServicesLib
>>> +
>>> +[Guids]
>>> +  gDtPlatformFormSetGuid
>>> +  gEdkiiPlatformHasAcpiGuid
>>> +  gDtPlatformDefaultDtbFileGuid
>>> +  gFdtTableGuid
>>> +
>>> +[Protocols]
>>> +  gEfiHiiConfigAccessProtocolGuid## PRODUCES
>
> I think this should have been dropped as well -- you can remove it when
> you commit the patch, 

Re: [edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Laszlo Ersek]

On 03/28/17 18:16, Ard Biesheuvel wrote:
> (use correct address for Marcin -- please take into account when replying)
> 
> On 28 March 2017 at 17:15, Ard Biesheuvel  wrote:
>> As a follow up to the changes proposed by Laszlo to make ACPI and DT
>> mutually exclusive on ArmVirtQemu, this patch proposed a DT platform

new typo relative to v1: s/proposed/proposes/

>> DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
>> or installs the FV embedded DTB binary as a configuration table under
>> the appropriate GUID, depending on a preference setting recorded as
>> a UEFI variable, and configurable via a HII screen.
>>
>> The DTB binary can be embedded in the firmware image by adding the
>> following to the platform .fdf file:
>>
>>   FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
>> SECTION RAW = SomePkg/path/to/foo.dtb
>>   }
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>> v2: fixup various errors and rough edges pointed out by Laszlo
>>
>>  EmbeddedPkg/EmbeddedPkg.dec |   6 +
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  65 ++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  31 +++
>>  EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
>>  EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  51 +
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 216 
>> 
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
>>  8 files changed, 442 insertions(+)
>>
>> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
>> index 29736fb4a71d..871fc5ff4016 100644
>> --- a/EmbeddedPkg/EmbeddedPkg.dec
>> +++ b/EmbeddedPkg/EmbeddedPkg.dec
>> @@ -62,6 +62,12 @@ [Guids.common]
>>## Include/Guid/PlatformHasDeviceTree.h
>>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
>> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>>
>> +  # HII form set GUID for DtPlatformDxe driver
>> +  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 
>> 0xdf, 0xa4, 0x41, 0x5f, 0x55, 0x26 } }
>> +
>> +  # File GUID for default DTB image embedded in the firmware volume
>> +  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 
>> 0x1d, 0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
>> +
>>  [Protocols.common]
>>gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
>> 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
>>gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 
>> 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
>> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf 
>> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
>> new file mode 100644
>> index ..aa1d3abb4012
>> --- /dev/null
>> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
>> @@ -0,0 +1,65 @@
>> +## @file
>> +#
>> +#  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
>> +#
>> +#  This program and the accompanying materials are licensed and made
>> +#  available under the terms and conditions of the BSD License which
>> +#  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.
>> +#
>> +##
>> +
>> +[Defines]
>> +  INF_VERSION   = 0x00010019
>> +  BASE_NAME = DtPlatformDxe
>> +  FILE_GUID = FC097B3C-2EBD-4A75-A3DA-121DCAB365CC
>> +  MODULE_TYPE   = DXE_DRIVER
>> +  VERSION_STRING= 1.0
>> +  ENTRY_POINT   = DtPlatformDxeEntryPoint
>> +
>> +#
>> +# The following information is for reference only and not required by the 
>> build tools.
>> +#
>> +#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
>> +#
>> +
>> +[Sources]
>> +  DtPlatformDxe.c
>> +  DtPlatformHii.vfr
>> +  DtPlatformHii.uni
>> +
>> +[Packages]
>> +  EmbeddedPkg/EmbeddedPkg.dec
>> +  MdePkg/MdePkg.dec
>> +  MdeModulePkg/MdeModulePkg.dec
>> +
>> +[LibraryClasses]
>> +  BaseLib
>> +  DebugLib
>> +  UefiLib
>> +  UefiDriverEntryPoint
>> +  UefiBootServicesTableLib
>> +  UefiRuntimeServicesTableLib
>> +  UefiHiiServicesLib
>> +  MemoryAllocationLib
>> +  HiiLib
>> +  PcdLib
>> +  DxeServicesLib
>> +
>> +[Guids]
>> +  gDtPlatformFormSetGuid
>> +  gEdkiiPlatformHasAcpiGuid
>> +  gDtPlatformDefaultDtbFileGuid
>> +  gFdtTableGuid
>> +
>> +[Protocols]
>> +  gEfiHiiConfigAccessProtocolGuid## PRODUCES

I think this should have been dropped as well -- you can remove it when
you commit the patch, if the removal works. (I think it should.)

>> +
>> +[Depex]
>> +  gEfiHiiDatabaseProtocolGuid AND

IMO this should have been dropped too. You are using UefiHiiServicesLib
(

Re: [edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

On 28 March 2017 at 17:16, Ard Biesheuvel  wrote:
> (use correct address for Marcin -- please take into account when replying)
>
> On 28 March 2017 at 17:15, Ard Biesheuvel  wrote:
>> As a follow up to the changes proposed by Laszlo to make ACPI and DT
>> mutually exclusive on ArmVirtQemu, this patch proposed a DT platform
>> DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
>> or installs the FV embedded DTB binary as a configuration table under
>> the appropriate GUID, depending on a preference setting recorded as
>> a UEFI variable, and configurable via a HII screen.
>>
>> The DTB binary can be embedded in the firmware image by adding the
>> following to the platform .fdf file:
>>
>>   FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
>> SECTION RAW = SomePkg/path/to/foo.dtb
>>   }
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>> v2: fixup various errors and rough edges pointed out by Laszlo
>>
>>  EmbeddedPkg/EmbeddedPkg.dec |   6 +
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  65 ++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  31 +++
>>  EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
>>  EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  51 +
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 216 
>> 
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
>>  8 files changed, 442 insertions(+)
>>
>> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
>> index 29736fb4a71d..871fc5ff4016 100644
>> --- a/EmbeddedPkg/EmbeddedPkg.dec
>> +++ b/EmbeddedPkg/EmbeddedPkg.dec
>> @@ -62,6 +62,12 @@ [Guids.common]
>>## Include/Guid/PlatformHasDeviceTree.h
>>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
>> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>>
>> +  # HII form set GUID for DtPlatformDxe driver
>> +  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 
>> 0xdf, 0xa4, 0x41, 0x5f, 0x55, 0x26 } }
>> +
>> +  # File GUID for default DTB image embedded in the firmware volume
>> +  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 
>> 0x1d, 0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
>> +
>>  [Protocols.common]
>>gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
>> 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
>>gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 
>> 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
>> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf 
>> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
>> new file mode 100644
>> index ..aa1d3abb4012
>> --- /dev/null
>> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
>> @@ -0,0 +1,65 @@
>> +## @file
>> +#
>> +#  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
>> +#
>> +#  This program and the accompanying materials are licensed and made
>> +#  available under the terms and conditions of the BSD License which
>> +#  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.
>> +#
>> +##
>> +
>> +[Defines]
>> +  INF_VERSION   = 0x00010019
>> +  BASE_NAME = DtPlatformDxe
>> +  FILE_GUID = FC097B3C-2EBD-4A75-A3DA-121DCAB365CC
>> +  MODULE_TYPE   = DXE_DRIVER
>> +  VERSION_STRING= 1.0
>> +  ENTRY_POINT   = DtPlatformDxeEntryPoint
>> +
>> +#
>> +# The following information is for reference only and not required by the 
>> build tools.
>> +#
>> +#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
>> +#
>> +
>> +[Sources]
>> +  DtPlatformDxe.c
>> +  DtPlatformHii.vfr
>> +  DtPlatformHii.uni
>> +
>> +[Packages]
>> +  EmbeddedPkg/EmbeddedPkg.dec
>> +  MdePkg/MdePkg.dec
>> +  MdeModulePkg/MdeModulePkg.dec
>> +
>> +[LibraryClasses]
>> +  BaseLib
>> +  DebugLib
>> +  UefiLib
>> +  UefiDriverEntryPoint
>> +  UefiBootServicesTableLib
>> +  UefiRuntimeServicesTableLib
>> +  UefiHiiServicesLib
>> +  MemoryAllocationLib
>> +  HiiLib
>> +  PcdLib
>> +  DxeServicesLib
>> +
>> +[Guids]
>> +  gDtPlatformFormSetGuid
>> +  gEdkiiPlatformHasAcpiGuid
>> +  gDtPlatformDefaultDtbFileGuid
>> +  gFdtTableGuid
>> +
>> +[Protocols]
>> +  gEfiHiiConfigAccessProtocolGuid## PRODUCES
>> +
>> +[Depex]
>> +  gEfiHiiDatabaseProtocolGuid AND
>> +  gEfiVariableArchProtocolGuidAND
>> +  gEfiVariableWriteArchProtocolGuid
>> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h 
>> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h
>> new file mode 100644
>> index 

Re: [edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

(use correct address for Marcin -- please take into account when replying)

On 28 March 2017 at 17:15, Ard Biesheuvel  wrote:
> As a follow up to the changes proposed by Laszlo to make ACPI and DT
> mutually exclusive on ArmVirtQemu, this patch proposed a DT platform
> DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
> or installs the FV embedded DTB binary as a configuration table under
> the appropriate GUID, depending on a preference setting recorded as
> a UEFI variable, and configurable via a HII screen.
>
> The DTB binary can be embedded in the firmware image by adding the
> following to the platform .fdf file:
>
>   FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
> SECTION RAW = SomePkg/path/to/foo.dtb
>   }
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
> v2: fixup various errors and rough edges pointed out by Laszlo
>
>  EmbeddedPkg/EmbeddedPkg.dec |   6 +
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  65 ++
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  31 +++
>  EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
>  EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  51 +
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 216 
> 
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
>  8 files changed, 442 insertions(+)
>
> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> index 29736fb4a71d..871fc5ff4016 100644
> --- a/EmbeddedPkg/EmbeddedPkg.dec
> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> @@ -62,6 +62,12 @@ [Guids.common]
>## Include/Guid/PlatformHasDeviceTree.h
>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>
> +  # HII form set GUID for DtPlatformDxe driver
> +  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 0xdf, 
> 0xa4, 0x41, 0x5f, 0x55, 0x26 } }
> +
> +  # File GUID for default DTB image embedded in the firmware volume
> +  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 
> 0x1d, 0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
> +
>  [Protocols.common]
>gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
> 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
>gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 
> 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf 
> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
> new file mode 100644
> index ..aa1d3abb4012
> --- /dev/null
> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
> @@ -0,0 +1,65 @@
> +## @file
> +#
> +#  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
> +#
> +#  This program and the accompanying materials are licensed and made
> +#  available under the terms and conditions of the BSD License which
> +#  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.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION   = 0x00010019
> +  BASE_NAME = DtPlatformDxe
> +  FILE_GUID = FC097B3C-2EBD-4A75-A3DA-121DCAB365CC
> +  MODULE_TYPE   = DXE_DRIVER
> +  VERSION_STRING= 1.0
> +  ENTRY_POINT   = DtPlatformDxeEntryPoint
> +
> +#
> +# The following information is for reference only and not required by the 
> build tools.
> +#
> +#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
> +#
> +
> +[Sources]
> +  DtPlatformDxe.c
> +  DtPlatformHii.vfr
> +  DtPlatformHii.uni
> +
> +[Packages]
> +  EmbeddedPkg/EmbeddedPkg.dec
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +  UefiLib
> +  UefiDriverEntryPoint
> +  UefiBootServicesTableLib
> +  UefiRuntimeServicesTableLib
> +  UefiHiiServicesLib
> +  MemoryAllocationLib
> +  HiiLib
> +  PcdLib
> +  DxeServicesLib
> +
> +[Guids]
> +  gDtPlatformFormSetGuid
> +  gEdkiiPlatformHasAcpiGuid
> +  gDtPlatformDefaultDtbFileGuid
> +  gFdtTableGuid
> +
> +[Protocols]
> +  gEfiHiiConfigAccessProtocolGuid## PRODUCES
> +
> +[Depex]
> +  gEfiHiiDatabaseProtocolGuid AND
> +  gEfiVariableArchProtocolGuidAND
> +  gEfiVariableWriteArchProtocolGuid
> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h 
> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h
> new file mode 100644
> index ..2369367277b0
> --- /dev/null
> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h
> @@ -0,0 +1,31 @@
> +/** @file
> +*
> +*  Copyright (c) 2017, Linaro Limited. All rights reser

[edk2] [PATCH v2] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

As a follow up to the changes proposed by Laszlo to make ACPI and DT
mutually exclusive on ArmVirtQemu, this patch proposed a DT platform
DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
or installs the FV embedded DTB binary as a configuration table under
the appropriate GUID, depending on a preference setting recorded as
a UEFI variable, and configurable via a HII screen.

The DTB binary can be embedded in the firmware image by adding the
following to the platform .fdf file:

  FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
SECTION RAW = SomePkg/path/to/foo.dtb
  }

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
v2: fixup various errors and rough edges pointed out by Laszlo

 EmbeddedPkg/EmbeddedPkg.dec |   6 +
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  65 ++
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  31 +++
 EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
 EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  51 +
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 216 
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
 8 files changed, 442 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 29736fb4a71d..871fc5ff4016 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -62,6 +62,12 @@ [Guids.common]
   ## Include/Guid/PlatformHasDeviceTree.h
   gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
 
+  # HII form set GUID for DtPlatformDxe driver
+  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 0xdf, 
0xa4, 0x41, 0x5f, 0x55, 0x26 } }
+
+  # File GUID for default DTB image embedded in the firmware volume
+  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 0x1d, 
0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
+
 [Protocols.common]
   gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
   gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, 
{ 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf 
b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
new file mode 100644
index ..aa1d3abb4012
--- /dev/null
+++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
@@ -0,0 +1,65 @@
+## @file
+#
+#  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made
+#  available under the terms and conditions of the BSD License which
+#  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.
+#
+##
+
+[Defines]
+  INF_VERSION   = 0x00010019
+  BASE_NAME = DtPlatformDxe
+  FILE_GUID = FC097B3C-2EBD-4A75-A3DA-121DCAB365CC
+  MODULE_TYPE   = DXE_DRIVER
+  VERSION_STRING= 1.0
+  ENTRY_POINT   = DtPlatformDxeEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
+#
+
+[Sources]
+  DtPlatformDxe.c
+  DtPlatformHii.vfr
+  DtPlatformHii.uni
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  UefiLib
+  UefiDriverEntryPoint
+  UefiBootServicesTableLib
+  UefiRuntimeServicesTableLib
+  UefiHiiServicesLib
+  MemoryAllocationLib
+  HiiLib
+  PcdLib
+  DxeServicesLib
+
+[Guids]
+  gDtPlatformFormSetGuid
+  gEdkiiPlatformHasAcpiGuid
+  gDtPlatformDefaultDtbFileGuid
+  gFdtTableGuid
+
+[Protocols]
+  gEfiHiiConfigAccessProtocolGuid## PRODUCES
+
+[Depex]
+  gEfiHiiDatabaseProtocolGuid AND
+  gEfiVariableArchProtocolGuidAND
+  gEfiVariableWriteArchProtocolGuid
diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h 
b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h
new file mode 100644
index ..2369367277b0
--- /dev/null
+++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h
@@ -0,0 +1,31 @@
+/** @file
+*
+*  Copyright (c) 2017, Linaro Limited. All rights reserved.
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which 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 REPRE

Re: [edk2] Reset from post BDS pahse to PEI phase

[Andrew Fish]

> On Mar 28, 2017, at 5:23 AM, Amit kumar  wrote:
> 
> 
> Hi ,
> I have been facing some problem with blockIO reads even after reconnect and 
> update map. when i try to do dblk on some of my blocks it returns with 
> EFI_INVALID_PARAMETER. 
> Is there a way to reinitialize the EFI platform from post bds phase or post 
> dxe phase without putting the board in power-off mode( like in the case of 
> shell reset command or system restart). 
> 

Amit,

If you look in the UEFI Spec you will see there is a Runtime Service called 
ResetSystem(). It supports different reset types, but it is up the platform to 
define what they are. For example a EfiWarmReset could end up being the same as 
EfiResetCold in a given implementation. I would assume the shell reset command 
maps directly into this call, so you can get background from reading the spec. 
on options to the shell reset command. 

I'd recommend looking in the UEFI Spec for the Block IO Protocol function 
definitions as the define a standardized set of return codes. 

For example ReadBlocks() EFI_INVALID_PARAMETER implies:
The read request contains LBAs that are not valid, or the buffer is not on 
proper alignment.

The information used by these checks comes from the Block IO protocol Media 
data (EFI_BLOCK_IO_MEDIA). EFI_BLOCK_IO_MEDIA.IoAlign would define buffer 
alignment requirements for the call, and  EFI_BLOCK_IO_MEDIA.LastBlock should 
define the valid LBA range. 

Maybe there is a strange alignment requirement and there is a bug in the Shell? 
Maybe the driver is not reporting a proper LastBlock?


Thanks,

Andrew Fish

> Thanks and Regards 
> Amit 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI

[Laszlo Ersek]

On 03/28/17 15:57, Ard Biesheuvel wrote:
> On 28 March 2017 at 14:50, Laszlo Ersek  wrote:
>> This is version 4 of the series posted (as v3) previously at
>> .
>>
>> Main changes in this version:
>>
>> * move gEdkiiPlatformHasAcpiGuid from MdeModulePkg to EmbeddedPkg (based
>>   on IRC discussion),
>>
>> * move PlatformHasAcpiLib from ArmPkg to EmbeddedPkg (based on IRC
>>   discussion),
>>
>> * the only two packages being touched are ArmVirtPkg and EmbeddedPkg
>>   now,
>>
>> * retest with a Fedora 25 guest (4.8.7-300.fc25.aarch64).
>>
>> Updates are also noted in detail on each patch individually.
>>
>> The series is fully reviewed by Ard (thanks!), I'm sending this out for
>> a final ACK before pushing.
>>
> 
> Looks good to me. Thanks for spending the time and effort!
> 

Thank you very much; pushed as 3efa3f3d05ea..89ad870fbff0.

Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI

[Laszlo Ersek]

This is version 4 of the series posted (as v3) previously at
.

Main changes in this version:

* move gEdkiiPlatformHasAcpiGuid from MdeModulePkg to EmbeddedPkg (based
  on IRC discussion),

* move PlatformHasAcpiLib from ArmPkg to EmbeddedPkg (based on IRC
  discussion),

* the only two packages being touched are ArmVirtPkg and EmbeddedPkg
  now,

* retest with a Fedora 25 guest (4.8.7-300.fc25.aarch64).

Updates are also noted in detail on each patch individually.

The series is fully reviewed by Ard (thanks!), I'm sending this out for
a final ACK before pushing.

Repo:   https://github.com/lersek/edk2.git
Branch: dt_acpi_v4
RHBZ:   https://bugzilla.redhat.com/show_bug.cgi?id=1430262

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 

Thanks,
Laszlo

Laszlo Ersek (12):
  Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI
dependent"
  Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at
ReadyToBoot"
  ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly
  EmbeddedPkg: introduce EDKII Platform Has ACPI GUID
  EmbeddedPkg: introduce PlatformHasAcpiLib
  EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID
  ArmVirtPkg: add PlatformHasAcpiDtDxe
  ArmVirtPkg: add XenPlatformHasAcpiDtDxe
  ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL
dynamically
  ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol
notify
  ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
  ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot

 ArmVirtPkg/ArmVirt.dsc.inc |   9 +-
 ArmVirtPkg/ArmVirtQemu.dsc |   1 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |   1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |   1 +
 ArmVirtPkg/ArmVirtXen.dsc  |   1 +
 ArmVirtPkg/ArmVirtXen.fdf  |   1 +
 ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 116 
++--
 ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf   |   4 +-
 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c |  86 
+++
 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   |  44 
 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c |   3 +-
 ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c   |  72 

 ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf |  42 +++
 EmbeddedPkg/EmbeddedPkg.dec|   6 +
 EmbeddedPkg/Include/Guid/PlatformHasAcpi.h |  35 ++
 EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h   |  35 ++
 EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c|  36 ++
 EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  |  40 +++
 18 files changed, 495 insertions(+), 38 deletions(-)
 create mode 100644 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
 create mode 100644 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
 create mode 100644 ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
 create mode 100644 
ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
 create mode 100644 EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
 create mode 100644 EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h
 create mode 100644 EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c
 create mode 100644 
EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf

-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI

[Ard Biesheuvel]

On 28 March 2017 at 14:50, Laszlo Ersek  wrote:
> This is version 4 of the series posted (as v3) previously at
> .
>
> Main changes in this version:
>
> * move gEdkiiPlatformHasAcpiGuid from MdeModulePkg to EmbeddedPkg (based
>   on IRC discussion),
>
> * move PlatformHasAcpiLib from ArmPkg to EmbeddedPkg (based on IRC
>   discussion),
>
> * the only two packages being touched are ArmVirtPkg and EmbeddedPkg
>   now,
>
> * retest with a Fedora 25 guest (4.8.7-300.fc25.aarch64).
>
> Updates are also noted in detail on each patch individually.
>
> The series is fully reviewed by Ard (thanks!), I'm sending this out for
> a final ACK before pushing.
>

Looks good to me. Thanks for spending the time and effort!

-- 
Ard.


> Repo:   https://github.com/lersek/edk2.git
> Branch: dt_acpi_v4
> RHBZ:   https://bugzilla.redhat.com/show_bug.cgi?id=1430262
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
>
> Thanks,
> Laszlo
>
> Laszlo Ersek (12):
>   Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI
> dependent"
>   Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at
> ReadyToBoot"
>   ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly
>   EmbeddedPkg: introduce EDKII Platform Has ACPI GUID
>   EmbeddedPkg: introduce PlatformHasAcpiLib
>   EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID
>   ArmVirtPkg: add PlatformHasAcpiDtDxe
>   ArmVirtPkg: add XenPlatformHasAcpiDtDxe
>   ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL
> dynamically
>   ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol
> notify
>   ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
>   ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot
>
>  ArmVirtPkg/ArmVirt.dsc.inc |   9 +-
>  ArmVirtPkg/ArmVirtQemu.dsc |   1 +
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |   1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc   |   1 +
>  ArmVirtPkg/ArmVirtXen.dsc  |   1 +
>  ArmVirtPkg/ArmVirtXen.fdf  |   1 +
>  ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 116 
> ++--
>  ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf   |   4 +-
>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c |  86 
> +++
>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   |  44 
>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c |   3 +-
>  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c   |  72 
> 
>  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf |  42 +++
>  EmbeddedPkg/EmbeddedPkg.dec|   6 +
>  EmbeddedPkg/Include/Guid/PlatformHasAcpi.h |  35 ++
>  EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h   |  35 ++
>  EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c|  36 ++
>  EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  |  40 +++
>  18 files changed, 495 insertions(+), 38 deletions(-)
>  create mode 100644 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>  create mode 100644 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>  create mode 100644 
> ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
>  create mode 100644 
> ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>  create mode 100644 EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
>  create mode 100644 EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h
>  create mode 100644 
> EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c
>  create mode 100644 
> EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot

[Laszlo Ersek]

The build flag and the FeaturePCD have no effect any longer, remove them.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up Ard's R-b

 ArmVirtPkg/ArmVirtPkg.dec  | 10 --
 ArmVirtPkg/ArmVirtQemu.dsc |  5 -
 2 files changed, 15 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index a5ec42166445..efe83a383d55 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -58,13 +58,3 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
   # EFI_VT_100_GUID.
   #
   gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 
0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 
0x4D}|VOID*|0x0007
-
-[PcdsFeatureFlag]
-  #
-  # Pure ACPI boot
-  #
-  # Inhibit installation of the FDT as a configuration table if this feature
-  # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
-  # description of the platform, and it is up to the OS to choose.
-  #
-  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x000a
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index c2427a6fcea2..4075b92aa2cb 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -34,7 +34,6 @@ [Defines]
   # -D FLAG=VALUE
   #
   DEFINE SECURE_BOOT_ENABLE  = FALSE
-  DEFINE PURE_ACPI_BOOT_ENABLE   = FALSE
 
 !include ArmVirtPkg/ArmVirt.dsc.inc
 
@@ -95,10 +94,6 @@ [PcdsFeatureFlag.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
 
-!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
-  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
-!endif
-
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
 !if $(ARCH) == AARCH64
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify

[Laszlo Ersek]

Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
notification callback. Move the sysconfig table installation from the
entry point function to the callback.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- replace gEdkiiPlatformHasDeviceTreeProtocolGuid with
  gEdkiiPlatformHasDeviceTreeGuid
- adapt Protocols / Guids sections in INF file
- drop now superfluous ArmPkg.dec dependency in INF file
- adapt include paths
- pick up Ard's R-b

 ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf |   4 +-
 ArmVirtPkg/FdtClientDxe/FdtClientDxe.c   | 105 ++--
 2 files changed, 97 insertions(+), 12 deletions(-)

diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf 
b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
index 3a0cd37040eb..8a5182a3ce99 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
@@ -42,11 +42,9 @@ [Protocols]
   gFdtClientProtocolGuid  ## PRODUCES
 
 [Guids]
+  gEdkiiPlatformHasDeviceTreeGuid ## CONSUMES ## PROTOCOL
   gFdtHobGuid
   gFdtTableGuid
 
-[FeaturePcd]
-  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
-
 [Depex]
   TRUE
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c 
b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
index 547a29fce62c..2d867b16fda8 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -306,6 +307,40 @@ STATIC FDT_CLIENT_PROTOCOL mFdtClientProtocol = {
   GetOrInsertChosenNode,
 };
 
+STATIC
+VOID
+EFIAPI
+OnPlatformHasDeviceTree (
+  IN EFI_EVENT Event,
+  IN VOID  *Context
+  )
+{
+  EFI_STATUS Status;
+  VOID   *Interface;
+  VOID   *DeviceTreeBase;
+
+  Status = gBS->LocateProtocol (
+  &gEdkiiPlatformHasDeviceTreeGuid,
+  NULL, // Registration
+  &Interface
+  );
+  if (EFI_ERROR (Status)) {
+return;
+  }
+
+  DeviceTreeBase = Context;
+  DEBUG ((
+DEBUG_INFO,
+"%a: exposing DTB @ 0x%p to OS\n",
+__FUNCTION__,
+DeviceTreeBase
+));
+  Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
+  ASSERT_EFI_ERROR (Status);
+
+  gBS->CloseEvent (Event);
+}
+
 EFI_STATUS
 EFIAPI
 InitializeFdtClientDxe (
@@ -316,6 +351,8 @@ InitializeFdtClientDxe (
   VOID  *Hob;
   VOID  *DeviceTreeBase;
   EFI_STATUSStatus;
+  EFI_EVENT PlatformHasDeviceTreeEvent;
+  VOID  *Registration;
 
   Hob = GetFirstGuidHob (&gFdtHobGuid);
   if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) {
@@ -333,15 +370,65 @@ InitializeFdtClientDxe (
 
   DEBUG ((EFI_D_INFO, "%a: DTB @ 0x%p\n", __FUNCTION__, mDeviceTreeBase));
 
-  if (!FeaturePcdGet (PcdPureAcpiBoot)) {
-//
-// Only install the FDT as a configuration table if we want to leave it up
-// to the OS to decide whether it prefers ACPI over DT.
-//
-Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
-ASSERT_EFI_ERROR (Status);
+  //
+  // Register a protocol notify for the EDKII Platform Has Device Tree
+  // Protocol.
+  //
+  Status = gBS->CreateEvent (
+  EVT_NOTIFY_SIGNAL,
+  TPL_CALLBACK,
+  OnPlatformHasDeviceTree,
+  DeviceTreeBase, // Context
+  &PlatformHasDeviceTreeEvent
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: CreateEvent(): %r\n", __FUNCTION__, Status));
+return Status;
   }
 
-  return gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
-EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
+  Status = gBS->RegisterProtocolNotify (
+  &gEdkiiPlatformHasDeviceTreeGuid,
+  PlatformHasDeviceTreeEvent,
+  &Registration
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: RegisterProtocolNotify(): %r\n",
+  __FUNCTION__,
+  Status
+  ));
+goto CloseEvent;
+  }
+
+  //
+  // Kick the event; the protocol could be available already.
+  //
+  Status = gBS->SignalEvent (PlatformHasDeviceTreeEvent);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: SignalEvent(): %r\n", __FUNCTION__, Status));
+goto CloseEvent;
+  }
+
+  Status = gBS->InstallProtocolInterface (
+  &ImageHandle,
+  &gFdtClientProtocolGuid,
+  EFI_NATIVE_INTERFACE,
+  &mFdtClientProtocol
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: InstallProtocolInterface(): %r\n",
+  __FUNCTION__,
+  Status
+  ));
+goto CloseEvent;
+  }
+
+  return Status;
+
+CloseEvent:
+  gBS->CloseEvent (Platfo

[edk2] [PATCH v4 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe

[Laszlo Ersek]

This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
according to ARM vs. AARCH64. At this point it differs from the QEMU
driver PlatformHasAcpiDtDxe in that this one always installs the DT.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v4:
- drop MdeModulePkg/MdeModulePkg.dec dependency

v3:
- update package dependencies in INF file according to the GUID
  relocations in prior patches (replace ArmPkg.dec with EmbeddedPkg.dec
  and MdeModulePkg.dec)
- drop superfluous ArmVirtPkg.dec package dependency
- rename gEdkiiPlatformHasAcpiProtocolGuid -> gEdkiiPlatformHasAcpiGuid
- rename gEdkiiPlatformHasDeviceTreeProtocolGuid ->
  gEdkiiPlatformHasDeviceTreeGuid
- adapt include paths and INF sections to protocol -> general GUID
  change
- pick up Ard's R-b

 ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 42 

 ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c   | 72 

 2 files changed, 114 insertions(+)

diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf 
b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
new file mode 100644
index ..2833075f65c9
--- /dev/null
+++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
@@ -0,0 +1,42 @@
+## @file
+# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+# hardware description to the operating system.
+#
+# Copyright (c) 2017, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which 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.
+##
+
+[Defines]
+  INF_VERSION= 1.25
+  BASE_NAME  = XenPlatformHasAcpiDtDxe
+  FILE_GUID  = 6914c46f-d46e-48dc-9998-8a5f64f02553
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= XenPlatformHasAcpiDt
+
+[Sources]
+  XenPlatformHasAcpiDtDxe.c
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Guids]
+  gEdkiiPlatformHasAcpiGuid   ## SOMETIMES_PRODUCES ## PROTOCOL
+  gEdkiiPlatformHasDeviceTreeGuid ## PRODUCES   ## PROTOCOL
+
+[Depex]
+  TRUE
diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c 
b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
new file mode 100644
index ..596f4ea8ddca
--- /dev/null
+++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
@@ -0,0 +1,72 @@
+/** @file
+  Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+  hardware description to the operating system.
+
+  Copyright (c) 2017, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which 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.
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+XenPlatformHasAcpiDt (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  EFI_STATUS Status;
+
+  //
+  // If we fail to install any of the necessary protocols below, the OS will be
+  // unbootable anyway (due to lacking hardware description), so tolerate no
+  // errors here.
+  //
+  // Always make ACPI available on 64-bit systems.
+  //
+  if (MAX_UINTN == MAX_UINT64) {
+Status = gBS->InstallProtocolInterface (
+&ImageHandle,
+&gEdkiiPlatformHasAcpiGuid,
+EFI_NATIVE_INTERFACE,
+NULL
+);
+if (EFI_ERROR (Status)) {
+  goto Failed;
+}
+  }
+
+  //
+  // Expose the Device Tree unconditionally.
+  //
+  Status = gBS->InstallProtocolInterface (
+  &ImageHandle,
+  &gEdkiiPlatformHasDeviceTreeGuid,
+  EFI_NATIVE_INTERFACE,
+  NULL
+  );
+  if (EFI_ERROR (Status)) {
+goto Failed;
+  }
+
+  return Status;
+
+Failed:
+  ASSERT_EFI_ERROR (Status);
+  CpuDeadLoop ();
+  //
+  // Keep compilers happy.
+  //
+  return Status;
+}
--

[edk2] [PATCH v4 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically

[Laszlo Ersek]

In this patch, the ACPI protocol / driver chain is enabled dynamically,
when appropriate. This is being done in one larger patch, because
ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform
DSCs.

No change in behavior should be observable after this patch on any
ArmVirtPkg platform.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v4:
- update pathname of plugin lib instance in dsc.inc to EmbeddedPkg
- pick up Ard's R-b

v3:
- don't enable dynamism for 32-bit (ARM) [Ard]

 ArmVirtPkg/ArmVirt.dsc.inc   | 9 -
 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 ArmVirtPkg/ArmVirtXen.dsc| 1 +
 ArmVirtPkg/ArmVirtXen.fdf| 1 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 6 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index f61fd0680612..e74eaf16e7ab 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -443,5 +443,12 @@ [Components.AARCH64]
   #
   # ACPI Support
   #
-  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
+
+  NULL|EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
+  }
+
+  #
+  # EBC support
+  #
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 4b556f309a6c..c2427a6fcea2 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -382,6 +382,7 @@ [Components.AARCH64]
   #
   # ACPI Support
   #
+  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
   
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
 
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 6b6555c889a3..c7317a056c0e 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -371,6 +371,7 @@ [Components.AARCH64]
   #
   # ACPI Support
   #
+  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
   
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
 
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 3422d1e5d996..679ca67ffa0f 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -222,5 +222,6 @@ [Components.common]
   # ACPI support
   #
 !if $(ARCH) == AARCH64
+  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
   ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
 !endif
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index c997251b12b8..aaae9755cd53 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -184,6 +184,7 @@ [FV.FvMain]
   # ACPI support
   #
 !if $(ARCH) == AARCH64
+  INF ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
   INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
   INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index cc5d12aaefea..b4381132c864 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -144,6 +144,7 @@ [FV.FvMain]
   #
   # ACPI Support
   #
+  INF ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
   INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
   INF 
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
-- 
2.9.3


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI

[Laszlo Ersek]

This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
the guest. Showing both is never needed (it is actually detrimental to the
adoption of standards, such as SBSA / SBBR).

* Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)

> Found FwCfg @ 0x9020008/0x902
> Found FwCfg DMA @ 0x9020010
> InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0

plus the usual messages. Later the guest kernel logs

> [0.00] efi:  SMBIOS 3.0=0x13bdb  ACPI 2.0=0x13844
>  MEMATTR=0x13a675018

before it lists the ACPI tables one by one.

In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches
the ACPI tables.

* With "-no-acpi", the firmware logs:

> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x902
> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
> PlatformHasAcpiDtDxe | InstallProtocolInterface:
> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0
> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
> FdtClientDxe | 0x13FFBF000 to OS
> ...
> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
> DXE_CORE | loaded!!
> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
> DXE_CORE | not loaded!!
> ...
> RamDiskDxe   | RamDiskAcpiCheck: Cannot locate the EFI ACPI
> RamDiskDxe   | Table Protocol, unable to publish RAM disks to
> RamDiskDxe   | NFIT.

(BootGraphicsResourceTableDxe's ReadyToBoot callback --
InstallBootGraphicsResourceTable() -- handles the lack of
EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs

> [0.00] efi:  SMBIOS 3.0=0x13bdb  MEMATTR=0x138caa018

In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches the directory "/sys/firmware/devicetree/base", which contains a
large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern
matches no files.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up MEMATTR log from repeated testing with Fedora guest (ACPI
  case) [Ard]
- extend the commit message with "/sys/firmware/devicetree/*" and
  "/sys/firmware/acpi/tables/*" pattern matching in the guest
- drop ArmVirtPkg.dec package dependency -- with the removal of the
  "pure ACPI boot" PCD dependency, ArmVirtPkg.dec actually becomes
  superfluous
- adapt patch to protocol -> generic GUID renaming
- pick up Ard's R-b

 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf |  7 +--
 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c   | 45 

 2 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
index 2450500b3f0e..4466bead57c2 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -25,14 +25,14 @@ [Sources]
   PlatformHasAcpiDtDxe.c
 
 [Packages]
-  ArmVirtPkg/ArmVirtPkg.dec
   EmbeddedPkg/EmbeddedPkg.dec
   MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
   BaseLib
   DebugLib
-  PcdLib
+  QemuFwCfgLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
 
@@ -40,8 +40,5 @@ [Guids]
   gEdkiiPlatformHasAcpiGuid   ## SOMETIMES_PRODUCES ## PROTOCOL
   gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
 
-[FeaturePcd]
-  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
-
 [Depex]
   TRUE
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c 
b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
index a718ce1b5a7b..8932dacabec5 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 EFI_STATUS
@@ -27,18 +27,27 @@ PlatformHasAcpiDt (
   IN EFI_SYSTEM_TABLE *SystemTable
   )
 {
-  EFI_STATUS Status;
-
-  Status = EFI_SUCCESS;
+  EFI_STATUS   Status;
+  FIRMWARE_CONFIG_ITEM FwCfgItem;
+  UINTNFwCfgSize;
 
   //
   // If we fail to install any of the necessary protocols below, the OS will be
   // unbootable anyway (due to lacking hardware description), so tolerate no
   // errors here.
   //
-  // Always make ACPI available on 64-bit systems.
-  //
-  if (MAX_UINTN == MAX_UINT64) {
+  if (MAX_UINTN == MAX_UINT64 &&
+  !EFI_ERROR (
+ QemuFwCfgFindFile (
+   "etc/table-loader",
+   &FwCfgItem,
+   &FwCfgSize
+   )
+ )) {
+//
+// Only make ACPI available on 64-bit systems, and only if QEMU generates
+// (a subset of) the ACPI tables.
+//
 S

[edk2] [PATCH v4 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe

[Laszlo Ersek]

This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v4:
- drop MdeModulePkg/MdeModulePkg.dec dependency

v3:
- update package dependencies in INF file according to the GUID
  relocations in prior patches (replace ArmPkg.dec with EmbeddedPkg.dec
  and MdeModulePkg.dec)
- rename gEdkiiPlatformHasAcpiProtocolGuid -> gEdkiiPlatformHasAcpiGuid
- rename gEdkiiPlatformHasDeviceTreeProtocolGuid ->
  gEdkiiPlatformHasDeviceTreeGuid
- adapt include paths and INF sections to protocol -> general GUID
  change
- pick up Ard's R-b

 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 47 
 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c   | 77 

 2 files changed, 124 insertions(+)

diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
new file mode 100644
index ..2450500b3f0e
--- /dev/null
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -0,0 +1,47 @@
+## @file
+# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+# hardware description to the operating system.
+#
+# Copyright (c) 2017, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which 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.
+##
+
+[Defines]
+  INF_VERSION= 1.25
+  BASE_NAME  = PlatformHasAcpiDtDxe
+  FILE_GUID  = 9d1dd27f-6d7f-427b-aec4-b62f6279c2f1
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= PlatformHasAcpiDt
+
+[Sources]
+  PlatformHasAcpiDtDxe.c
+
+[Packages]
+  ArmVirtPkg/ArmVirtPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  PcdLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Guids]
+  gEdkiiPlatformHasAcpiGuid   ## SOMETIMES_PRODUCES ## PROTOCOL
+  gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
+
+[FeaturePcd]
+  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
+
+[Depex]
+  TRUE
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c 
b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
new file mode 100644
index ..a718ce1b5a7b
--- /dev/null
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
@@ -0,0 +1,77 @@
+/** @file
+  Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+  hardware description to the operating system.
+
+  Copyright (c) 2017, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which 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.
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+PlatformHasAcpiDt (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  EFI_STATUS Status;
+
+  Status = EFI_SUCCESS;
+
+  //
+  // If we fail to install any of the necessary protocols below, the OS will be
+  // unbootable anyway (due to lacking hardware description), so tolerate no
+  // errors here.
+  //
+  // Always make ACPI available on 64-bit systems.
+  //
+  if (MAX_UINTN == MAX_UINT64) {
+Status = gBS->InstallProtocolInterface (
+&ImageHandle,
+&gEdkiiPlatformHasAcpiGuid,
+EFI_NATIVE_INTERFACE,
+NULL
+);
+if (EFI_ERROR (Status)) {
+  goto Failed;
+}
+  }
+
+  //
+  // Expose the Device Tree unless PcdPureAcpiBoot is set.
+  //
+  if (!FeaturePcdGet (PcdPureAcpiBoot)) {
+Status = gBS->InstallProtocolInterface (
+&ImageHandle,
+&gEdkiiPlatformHasDeviceTreeGuid,
+EFI_NATIVE_INTERFACE,
+NULL
+);
+if (EFI_ERROR (Status)) {
+  goto Failed;
+}
+  }
+
+  return Status;
+
+Failed:
+  ASSERT_EFI_ERROR (Status);
+  CpuDeadLoop ();
+  //
+  // Keep

[edk2] [PATCH v4 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot"

[Laszlo Ersek]

This reverts commit 18f6d4df9ece8b91b86511bcdd1cf7da478c3627.

We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.

This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up Ard's R-b

 ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf |  1 -
 ArmVirtPkg/FdtClientDxe/FdtClientDxe.c   | 49 
 2 files changed, 9 insertions(+), 41 deletions(-)

diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf 
b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
index 00017727c32c..3a0cd37040eb 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
@@ -42,7 +42,6 @@ [Protocols]
   gFdtClientProtocolGuid  ## PRODUCES
 
 [Guids]
-  gEfiEventReadyToBootGuid
   gFdtHobGuid
   gFdtTableGuid
 
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c 
b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
index 4cf79f70cb2a..547a29fce62c 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
@@ -307,30 +306,6 @@ STATIC FDT_CLIENT_PROTOCOL mFdtClientProtocol = {
   GetOrInsertChosenNode,
 };
 
-STATIC
-VOID
-EFIAPI
-OnReadyToBoot (
-  EFI_EVENT   Event,
-  VOID*Context
-  )
-{
-  EFI_STATUS  Status;
-
-  if (!FeaturePcdGet (PcdPureAcpiBoot)) {
-//
-// Only install the FDT as a configuration table if we want to leave it up
-// to the OS to decide whether it prefers ACPI over DT.
-//
-Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
-ASSERT_EFI_ERROR (Status);
-  }
-
-  gBS->CloseEvent (Event);
-}
-
-STATIC EFI_EVENT mReadyToBootEvent;
-
 EFI_STATUS
 EFIAPI
 InitializeFdtClientDxe (
@@ -358,21 +333,15 @@ InitializeFdtClientDxe (
 
   DEBUG ((EFI_D_INFO, "%a: DTB @ 0x%p\n", __FUNCTION__, mDeviceTreeBase));
 
-  Status = gBS->InstallProtocolInterface (&ImageHandle, 
&gFdtClientProtocolGuid,
-  EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
-  if (EFI_ERROR (Status)) {
-return Status;
+  if (!FeaturePcdGet (PcdPureAcpiBoot)) {
+//
+// Only install the FDT as a configuration table if we want to leave it up
+// to the OS to decide whether it prefers ACPI over DT.
+//
+Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
+ASSERT_EFI_ERROR (Status);
   }
 
-  Status = gBS->CreateEventEx (
-  EVT_NOTIFY_SIGNAL,
-  TPL_CALLBACK,
-  OnReadyToBoot,
-  NULL,
-  &gEfiEventReadyToBootGuid,
-  &mReadyToBootEvent
-  );
-  ASSERT_EFI_ERROR (Status);
-
-  return EFI_SUCCESS;
+  return gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
+EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
 }
-- 
2.9.3


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 06/12] EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID

[Laszlo Ersek]

The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with a Device
Tree-based hardware description. This is not necessarily exclusive with
other types of hardware description (for example, an ACPI-based one).

A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.

In the DXE phase, the protocol is meant to be consumed by the platform
driver that
- owns the Device Tree description of the hardware, and
- is responsible for installing it as a system configuration table.

Said FDT-owner driver can wait for the protocol via DEPEX or protocol
notify.

Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere (for example in MdeModulePkg and SecurityPkg).

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v4:
- pick up Ard's R-b

v3:
- move GUID from ArmPkg to EmbeddedPkg [Leif]
- apply the protocol -> generic GUID changes to naming, comments, and
  the commit message, that were suggested by Star for the MdeModulePkg /
  ACPI counterpart

 EmbeddedPkg/EmbeddedPkg.dec  |  3 ++
 EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h | 35 
 2 files changed, 38 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index d078bf794a79..29736fb4a71d 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -59,6 +59,9 @@ [Guids.common]
   ## Include/Guid/PlatformHasAcpi.h
   gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
 
+  ## Include/Guid/PlatformHasDeviceTree.h
+  gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
+
 [Protocols.common]
   gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
   gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, 
{ 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
diff --git a/EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h 
b/EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h
new file mode 100644
index ..a9bc51270cda
--- /dev/null
+++ b/EmbeddedPkg/Include/Guid/PlatformHasDeviceTree.h
@@ -0,0 +1,35 @@
+/** @file
+  EDKII Platform Has Device Tree GUID
+
+  A NULL protocol instance with this GUID in the DXE protocol database, and/or
+  a NULL PPI with this GUID in the PPI database, implies that the platform
+  provides the operating system with a Device Tree-based hardware description.
+  Note that this is not necessarily exclusive with different kinds of hardware
+  description (for example, an ACPI-based one). A platform driver and/or PEIM
+  is supposed to produce a single instance of the protocol and/or PPI (with
+  NULL contents), if appropriate.
+
+  Copyright (C) 2017, Red Hat, Inc.
+
+  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 __EDKII_PLATFORM_HAS_DEVICE_TREE_H__
+#define __EDKII_PLATFORM_HAS_DEVICE_TREE_H__
+
+#define EDKII_PLATFORM_HAS_DEVICE_TREE_GUID \
+  { \
+0x7ebb920d, 0x1aaf, 0x46d9, \
+{ 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } \
+  }
+
+extern EFI_GUID gEdkiiPlatformHasDeviceTreeGuid;
+
+#endif
-- 
2.9.3


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 04/12] EmbeddedPkg: introduce EDKII Platform Has ACPI GUID

[Laszlo Ersek]

The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with an ACPI-based
hardware description. This is not necessarily exclusive with other types
of hardware description (for example, a Device Tree-based one).

A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.

In the DXE phase, the protocol is meant to be depended-upon by
"MdeModulePkg/Universal/Acpi/AcpiTableDxe", indirectly:

* In the long term, interested platforms will establish this dependency by
  hooking an (upcoming) NULL-class DepexLib instance into AcpiTableDxe in
  their DSC files, pointing DepexLib's DEPEX through a FixedAtBuild PCD to
  the GUID introduced here. (For the prerequisite BaseTools feature, refer
  to ).

* In the short term, an interested platform may hook a private NULL-class
  library instance (called e.g. "PlatformHasAcpiLib") into AcpiTableDxe.
  Such a library instance would be a specialization of the above described
  generic DepexLib, with the DEPEX open-coded on the GUID introduced here.

Either way, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled)
EFI_ACPI_SDT_PROTOCOL dependent on the platform's dynamic decision to
produce or not to produce a NULL protocol instance with this GUID.

In turn, other (platform and universal) DXE drivers that produce ACPI
tables will wait for EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL, via
DEPEX, protocol notify, or a simple gBS->LocateProtocol() in a "late
enough" callback (such as Ready To Boot).

Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere in MdeModulePkg and SecurityPkg. In addition, an effort is
made to avoid the phrase "AcpiPlatform", as that belongs to drivers /
libraries that produce platform specific ACPI content (as opposed to
deciding whether the entire firmware will have access to
EFI_ACPI_TABLE_PROTOCOL, or any similar facilities in the PEI phase).

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v4:
- move to EmbeddedPkg [Ard, Laszlo]
- fix BZ reference (#444 is for docs, #443 is BaseTools code) [Laszlo]
- pick up Ard's R-b

v3:
- rename gEdkiiPlatformHasAcpiProtocolGuid to gEdkiiPlatformHasAcpiGuid
  [Star]
- update commit message and code comments to reflect possible use as a
  PPI as well [Star]
- move GUID from ArmPkg to MdeModulePkg [Leif, Ard]
- split PlatformHasAcpiLib to a separate patch [Star]

 EmbeddedPkg/EmbeddedPkg.dec|  3 ++
 EmbeddedPkg/Include/Guid/PlatformHasAcpi.h | 35 
 2 files changed, 38 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 2c2cf41103c2..d078bf794a79 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -56,6 +56,9 @@ [Guids.common]
   gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
0xAD, 0x3F, 0x71, 0x6D } }
   gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 
0x4e, 0xfb, 0x3e, 0x57 } }
 
+  ## Include/Guid/PlatformHasAcpi.h
+  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
+
 [Protocols.common]
   gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
   gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, 
{ 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
diff --git a/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h 
b/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
new file mode 100644
index ..ad517821375d
--- /dev/null
+++ b/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
@@ -0,0 +1,35 @@
+/** @file
+  EDKII Platform Has ACPI GUID
+
+  A NULL protocol instance with this GUID in the DXE protocol database, and/or
+  a NULL PPI with this GUID in the PPI database, implies that the platform
+  provides the operating system with an ACPI-based hardware description. Note
+  that this is not necessarily exclusive with different kinds of hardware
+  description (for example, a Device Tree-based one). A platform driver and/or
+  PEIM is supposed to produce a single instance of the protocol and/or PPI
+  (with NULL contents), if appropriate.
+
+  Copyright (C) 2017, Red Hat, Inc.
+
+  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 lice

[edk2] [PATCH v4 05/12] EmbeddedPkg: introduce PlatformHasAcpiLib

[Laszlo Ersek]

Add the shorter-term library instance outlined in the previous patch to
EmbeddedPkg, so that we can imbue AcpiTableDxe with a protocol dependency
on EDKII_PLATFORM_HAS_ACPI_GUID.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v4:
- move to EmbeddedPkg [Ard, Laszlo]
- refresh commit message
- redirect INF / LibraryClasses to EmbeddedPkg.dec
- pick up Ard's R-b

v3:
- move GUID to MdeModulePkg (see previous patch) [Leif, Ard]
- replace ArmPkg.dec package dependency with MdeModulePkg.dec in INF
  file
- rename gEdkiiPlatformHasAcpiProtocolGuid to gEdkiiPlatformHasAcpiGuid
  [Star]
- update comment in empty constructor function accordingly

 EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf | 40 

 EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c   | 36 
++
 2 files changed, 76 insertions(+)

diff --git a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf 
b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
new file mode 100644
index ..6268293ca97b
--- /dev/null
+++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
@@ -0,0 +1,40 @@
+## @file
+# A hook-in library for MdeModulePkg/Universal/Acpi/AcpiTableDxe.
+#
+# Plugging this library instance into AcpiTableDxe makes
+# EFI_ACPI_TABLE_PROTOCOL and (if enabled) EFI_ACPI_SDT_PROTOCOL depend on the
+# platform's dynamic decision whether to expose an ACPI-based hardware
+# description to the operating system.
+#
+# Universal and platform specific DXE drivers that produce ACPI tables depend
+# on EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL in turn.
+#
+# Copyright (C) 2017, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which 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.
+##
+
+[Defines]
+  INF_VERSION= 1.25
+  BASE_NAME  = PlatformHasAcpiLib
+  FILE_GUID  = 29beb028-0958-447b-be0a-12229235d77d
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PlatformHasAcpiLib|DXE_DRIVER
+  CONSTRUCTOR= PlatformHasAcpiInitialize
+
+[Sources]
+  PlatformHasAcpiLib.c
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+
+[Depex]
+  gEdkiiPlatformHasAcpiGuid
diff --git a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c 
b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c
new file mode 100644
index ..2c73e71769eb
--- /dev/null
+++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c
@@ -0,0 +1,36 @@
+/** @file
+  A hook-in library for MdeModulePkg/Universal/Acpi/AcpiTableDxe.
+
+  Plugging this library instance into AcpiTableDxe makes
+  EFI_ACPI_TABLE_PROTOCOL and (if enabled) EFI_ACPI_SDT_PROTOCOL depend on the
+  platform's dynamic decision whether to expose an ACPI-based hardware
+  description to the operating system.
+
+  Universal and platform specific DXE drivers that produce ACPI tables depend
+  on EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL in turn.
+
+  Copyright (C) 2017, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which 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.
+**/
+
+#include 
+
+RETURN_STATUS
+EFIAPI
+PlatformHasAcpiInitialize (
+  VOID
+  )
+{
+  //
+  // Do nothing, just imbue AcpiTableDxe with a protocol dependency on
+  // EDKII_PLATFORM_HAS_ACPI_GUID.
+  //
+  return RETURN_SUCCESS;
+}
-- 
2.9.3


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent"

[Laszlo Ersek]

This reverts commit 78c41ff519b187d8979cda7074f007a6323f9acd.

We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.

This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up Ard's R-b

 ArmVirtPkg/ArmVirtPkg.dec| 10 ++
 ArmVirtPkg/ArmVirtQemu.dsc   |  5 +
 ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf |  5 +++--
 ArmVirtPkg/FdtClientDxe/FdtClientDxe.c   | 16 +---
 4 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index efe83a383d55..a5ec42166445 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -58,3 +58,13 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
   # EFI_VT_100_GUID.
   #
   gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 
0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 
0x4D}|VOID*|0x0007
+
+[PcdsFeatureFlag]
+  #
+  # Pure ACPI boot
+  #
+  # Inhibit installation of the FDT as a configuration table if this feature
+  # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
+  # description of the platform, and it is up to the OS to choose.
+  #
+  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x000a
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 4f686faa559c..4b556f309a6c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -34,6 +34,7 @@ [Defines]
   # -D FLAG=VALUE
   #
   DEFINE SECURE_BOOT_ENABLE  = FALSE
+  DEFINE PURE_ACPI_BOOT_ENABLE   = FALSE
 
 !include ArmVirtPkg/ArmVirt.dsc.inc
 
@@ -94,6 +95,10 @@ [PcdsFeatureFlag.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
 
+!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
+  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
+!endif
+
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
 !if $(ARCH) == AARCH64
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf 
b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
index 9861f41e968b..00017727c32c 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
@@ -37,16 +37,17 @@ [LibraryClasses]
   HobLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
-  UefiLib
 
 [Protocols]
   gFdtClientProtocolGuid  ## PRODUCES
 
 [Guids]
-  gEfiAcpi20TableGuid
   gEfiEventReadyToBootGuid
   gFdtHobGuid
   gFdtTableGuid
 
+[FeaturePcd]
+  gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
+
 [Depex]
   TRUE
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c 
b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
index 21c1074e331c..4cf79f70cb2a 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
@@ -17,11 +17,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -318,16 +316,12 @@ OnReadyToBoot (
   )
 {
   EFI_STATUS  Status;
-  VOID*Table;
 
-  //
-  // Only install the FDT as a configuration table if we are not exposing
-  // ACPI 2.0 (or later) tables. Note that the legacy ACPI table GUID has
-  // no meaning on ARM since we need at least ACPI 5.0 support, and the
-  // 64-bit ACPI 2.0 table GUID is mandatory in that case.
-  //
-  Status = EfiGetSystemConfigurationTable (&gEfiAcpi20TableGuid, &Table);
-  if (EFI_ERROR (Status) || Table == NULL) {
+  if (!FeaturePcdGet (PcdPureAcpiBoot)) {
+//
+// Only install the FDT as a configuration table if we want to leave it up
+// to the OS to decide whether it prefers ACPI over DT.
+//
 Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
 ASSERT_EFI_ERROR (Status);
   }
-- 
2.9.3


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 03/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly

[Laszlo Ersek]

Because that breaks the (potential) 32-bit build of the driver.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- modify commit message (s/upcoming/potential/ build) to reflect that we
  won't actually include the ACPI stuff in the 32-bit builds [Ard]
- pick up Ard's R-b

 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c 
b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
index 203946f97bf8..49f9b5d2822a 100644
--- a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
+++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
@@ -73,7 +73,8 @@ GetXenArmAcpiRsdp (
   ASSERT (RegSize == 2 * sizeof (UINT64));
 
   RegBase = SwapBytes64(Reg[0]);
-  RsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)RegBase;
+  RsdpStructurePtr =
+(EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)(UINTN)RegBase;
 
   if (RsdpStructurePtr && RsdpStructurePtr->Revision >= 2) {
 Sum = CalculateSum8 ((CONST UINT8 *)RsdpStructurePtr,
-- 
2.9.3


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] SignedCapsulePkg: Update RecoveryModuleLoadPei to report the correct FvInfo

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, March 28, 2017 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch] SignedCapsulePkg: Update RecoveryModuleLoadPei to report
> the correct FvInfo
> 
> Update logic to install FvInfo PPI with its file system guid.
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  .../Universal/RecoveryModuleLoadPei/RecoveryModuleLoadPei.c   |
> 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git
> a/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/RecoveryModuleLoadP
> ei.c
> b/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/RecoveryModuleLoad
> Pei.c
> index c8c5ba0..c22e3a4 100644
> ---
> a/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/RecoveryModuleLoadP
> ei.c
> +++
> b/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/RecoveryModuleLoad
> Pei.c
> @@ -9,7 +9,7 @@
>ProcessRecoveryCapsule(), ProcessFmpCapsuleImage(),
> ProcessRecoveryImage(),
>ValidateFmpCapsule() will receive untrusted input and do basic validation.
> 
> -Copyright (c) 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -467,7 +467,7 @@ CreateHobForRecoveryCapsule (
>DEBUG((DEBUG_INFO, "BuildFvHob (FV in recovery) - 0x%lx - 0x%lx\n",
> (UINT64)(UINTN)FvHeader, FvHeader->FvLength));
> 
>PeiServicesInstallFvInfoPpi(
> -NULL,
> +&FvHeader->FileSystemGuid,
>  (VOID *)FvHeader,
>  (UINT32)FvHeader->FvLength,
>  NULL,
> --
> 2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Reset from post BDS pahse to PEI phase

[Amit kumar]

Hi ,
I have been facing some problem with blockIO reads even after reconnect and 
update map. when i try to do dblk on some of my blocks it returns with 
EFI_INVALID_PARAMETER. 
Is there a way to reinitialize the EFI platform from post bds phase or post dxe 
phase without putting the board in power-off mode( like in the case of shell 
reset command or system restart). 

Thanks and Regards 
Amit 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Laszlo Ersek]

On 03/28/17 12:51, Ard Biesheuvel wrote:
> On 28 March 2017 at 11:49, Laszlo Ersek  wrote:
>> On 03/28/17 12:43, Laszlo Ersek wrote:
>>> Ard,
>>>
>>> On 03/27/17 12:07, Ard Biesheuvel wrote:
>>
>> [snip]
>>
 +/**
 +  The entry point for DtPlatformDxe driver.
 +
 +  @param[in] ImageHandle The image handle of the driver.
 +  @param[in] SystemTable The system table.
 +
 +  @retval EFI_ALREADY_STARTED The driver already exists in system.
 +  @retval EFI_OUT_OF_RESOURCESFail to execute entry point due to lack 
 of
 +  resources.
 +  @retval EFI_SUCCES  All the related protocols are installed 
 on
 +  the driver.
 +
 +**/
 +EFI_STATUS
 +EFIAPI
 +DtPlatformDxeEntryPoint (
 +  IN EFI_HANDLE   ImageHandle,
 +  IN EFI_SYSTEM_TABLE *SystemTable
 +  )
 +{
 +  EFI_STATUS  Status;
 +  EFI_HANDLE  DriverHandle;
 +  DT_ACPI_VARSTORE_DATA   DtAcpiPref;
 +  UINTN   BufferSize;
 +  VOID*Dtb;
 +  UINTN   DtbSize;
 +  VOID*DtbCopy;
 +
 +  //
 +  // Check whether a DTB blob is included in the firmware image.
 +  //
 +  Dtb = NULL;
 +  Status = GetSectionFromAnyFv (&gDtPlatformDefaultDtbFileGuid,
 + EFI_SECTION_RAW, 0, &Dtb, &DtbSize);
 +  if (EFI_ERROR (Status)) {
 +DEBUG ((DEBUG_WARN, "%a: no DTB blob found, defaulting to ACPI\n",
 +  __FUNCTION__));
 +DtAcpiPref.Pref = DT_ACPI_SELECT_ACPI;
 +  } else {
 +//
 +// Get the current ACPI/DT preference from the AcpiDtPref variable.
 +//
>>>
>>> The comment says "AcpiDtPref variable" (which corresponds to the name under 
>>> which the VFR also refers to the variable), but below the variable services 
>>> actually get a "DtAcpiPref" argument as variable name.
>>>
>>> Please fix this inconsistency together with the other instances.
>>>
 +BufferSize = sizeof (DtAcpiPref);
 +Status = gRT->GetVariable(L"DtAcpiPref", &gDtPlatformFormSetGuid, 
 NULL,
 +&BufferSize, &DtAcpiPref);
 +if (EFI_ERROR (Status)) {
 +  DEBUG ((DEBUG_WARN, "%a: no DT/ACPI preference found, defaulting to 
 DT\n",
 +__FUNCTION__));
 +  DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
 +}
 +  }
 +
 +  if (!EFI_ERROR (Status) &&
 +  DtAcpiPref.Pref != DT_ACPI_SELECT_ACPI &&
 +  DtAcpiPref.Pref != DT_ACPI_SELECT_DT) {
 +DEBUG ((DEBUG_WARN, "%a: illegal value for DtAcpiPref, defaulting to 
 DT\n",
 +  __FUNCTION__));
>>>
>>> Personal request: please replace "illegal" with "invalid".
>>>
 +DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
 +Status = EFI_INVALID_PARAMETER; // trigger setvar below
 +  }
 +
 +  //
 +  // Write the newly selected default value back to the variable store.
 +  //
 +  if (EFI_ERROR (Status)) {
 +Status = gRT->SetVariable(L"DtAcpiPref", &gDtPlatformFormSetGuid,
 +EFI_VARIABLE_NON_VOLATILE | 
 EFI_VARIABLE_BOOTSERVICE_ACCESS,
 +sizeof (DtAcpiPref), &DtAcpiPref);
>>>
>>> I suggest to use a macro for the variable name...
>>>
 +if (EFI_ERROR (Status)) {
 +  return Status;
 +}
 +  }
 +
 +  if (DtAcpiPref.Pref == DT_ACPI_SELECT_ACPI) {
 +//
 +// ACPI was selected: install the gEdkiiPlatformHasAcpiGuid GUID as a
 +// NULL protocol to unlock dispatch of ACPI related drivers.
 +//
 +DriverHandle = NULL;
 +Status = gBS->InstallMultipleProtocolInterfaces (&DriverHandle,
 +gEdkiiPlatformHasAcpiGuid, NULL, NULL);
 +if (EFI_ERROR (Status)) {
 +  DEBUG ((DEBUG_ERROR,
 +"%a: failed to install gEdkiiPlatformHasAcpiGuid as a protocol\n",
 +__FUNCTION__));
 +  return Status;
 +}
>>>
>>> I think you don't need to create a new controller handle for 
>>> gEdkiiPlatformHasAcpiGuid; using ImageHandle should be fine.
>>>
>>> (Same for gEfiDevicePathProtocolGuid in InstallHiiPages().)
>>>
>>> Not critical though, just simpler perhaps.
>>>
 +  } else if (DtAcpiPref.Pref == DT_ACPI_SELECT_DT) {
 +//
 +// DT was selected: copy the blob into newly allocated memory and 
 install
 +// a reference to it as the FDT configuration table.
 +//
 +DtbCopy = AllocateCopyPool (DtbSize, Dtb);
 +if (DtbCopy == NULL) {
 +  return EFI_OUT_OF_RESOURCES;
 +}
 +Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DtbCopy);
 +if (EFI_ERROR (Status)) {
 +  DEBUG ((DEBUG_ERROR, "%a: failed to install FD

Re: [edk2] [PATCH] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

On 28 March 2017 at 11:49, Laszlo Ersek  wrote:
> On 03/28/17 12:43, Laszlo Ersek wrote:
>> Ard,
>>
>> On 03/27/17 12:07, Ard Biesheuvel wrote:
>
> [snip]
>
>>> +/**
>>> +  The entry point for DtPlatformDxe driver.
>>> +
>>> +  @param[in] ImageHandle The image handle of the driver.
>>> +  @param[in] SystemTable The system table.
>>> +
>>> +  @retval EFI_ALREADY_STARTED The driver already exists in system.
>>> +  @retval EFI_OUT_OF_RESOURCESFail to execute entry point due to lack 
>>> of
>>> +  resources.
>>> +  @retval EFI_SUCCES  All the related protocols are installed 
>>> on
>>> +  the driver.
>>> +
>>> +**/
>>> +EFI_STATUS
>>> +EFIAPI
>>> +DtPlatformDxeEntryPoint (
>>> +  IN EFI_HANDLE   ImageHandle,
>>> +  IN EFI_SYSTEM_TABLE *SystemTable
>>> +  )
>>> +{
>>> +  EFI_STATUS  Status;
>>> +  EFI_HANDLE  DriverHandle;
>>> +  DT_ACPI_VARSTORE_DATA   DtAcpiPref;
>>> +  UINTN   BufferSize;
>>> +  VOID*Dtb;
>>> +  UINTN   DtbSize;
>>> +  VOID*DtbCopy;
>>> +
>>> +  //
>>> +  // Check whether a DTB blob is included in the firmware image.
>>> +  //
>>> +  Dtb = NULL;
>>> +  Status = GetSectionFromAnyFv (&gDtPlatformDefaultDtbFileGuid,
>>> + EFI_SECTION_RAW, 0, &Dtb, &DtbSize);
>>> +  if (EFI_ERROR (Status)) {
>>> +DEBUG ((DEBUG_WARN, "%a: no DTB blob found, defaulting to ACPI\n",
>>> +  __FUNCTION__));
>>> +DtAcpiPref.Pref = DT_ACPI_SELECT_ACPI;
>>> +  } else {
>>> +//
>>> +// Get the current ACPI/DT preference from the AcpiDtPref variable.
>>> +//
>>
>> The comment says "AcpiDtPref variable" (which corresponds to the name under 
>> which the VFR also refers to the variable), but below the variable services 
>> actually get a "DtAcpiPref" argument as variable name.
>>
>> Please fix this inconsistency together with the other instances.
>>
>>> +BufferSize = sizeof (DtAcpiPref);
>>> +Status = gRT->GetVariable(L"DtAcpiPref", &gDtPlatformFormSetGuid, NULL,
>>> +&BufferSize, &DtAcpiPref);
>>> +if (EFI_ERROR (Status)) {
>>> +  DEBUG ((DEBUG_WARN, "%a: no DT/ACPI preference found, defaulting to 
>>> DT\n",
>>> +__FUNCTION__));
>>> +  DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
>>> +}
>>> +  }
>>> +
>>> +  if (!EFI_ERROR (Status) &&
>>> +  DtAcpiPref.Pref != DT_ACPI_SELECT_ACPI &&
>>> +  DtAcpiPref.Pref != DT_ACPI_SELECT_DT) {
>>> +DEBUG ((DEBUG_WARN, "%a: illegal value for DtAcpiPref, defaulting to 
>>> DT\n",
>>> +  __FUNCTION__));
>>
>> Personal request: please replace "illegal" with "invalid".
>>
>>> +DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
>>> +Status = EFI_INVALID_PARAMETER; // trigger setvar below
>>> +  }
>>> +
>>> +  //
>>> +  // Write the newly selected default value back to the variable store.
>>> +  //
>>> +  if (EFI_ERROR (Status)) {
>>> +Status = gRT->SetVariable(L"DtAcpiPref", &gDtPlatformFormSetGuid,
>>> +EFI_VARIABLE_NON_VOLATILE | 
>>> EFI_VARIABLE_BOOTSERVICE_ACCESS,
>>> +sizeof (DtAcpiPref), &DtAcpiPref);
>>
>> I suggest to use a macro for the variable name...
>>
>>> +if (EFI_ERROR (Status)) {
>>> +  return Status;
>>> +}
>>> +  }
>>> +
>>> +  if (DtAcpiPref.Pref == DT_ACPI_SELECT_ACPI) {
>>> +//
>>> +// ACPI was selected: install the gEdkiiPlatformHasAcpiGuid GUID as a
>>> +// NULL protocol to unlock dispatch of ACPI related drivers.
>>> +//
>>> +DriverHandle = NULL;
>>> +Status = gBS->InstallMultipleProtocolInterfaces (&DriverHandle,
>>> +gEdkiiPlatformHasAcpiGuid, NULL, NULL);
>>> +if (EFI_ERROR (Status)) {
>>> +  DEBUG ((DEBUG_ERROR,
>>> +"%a: failed to install gEdkiiPlatformHasAcpiGuid as a protocol\n",
>>> +__FUNCTION__));
>>> +  return Status;
>>> +}
>>
>> I think you don't need to create a new controller handle for 
>> gEdkiiPlatformHasAcpiGuid; using ImageHandle should be fine.
>>
>> (Same for gEfiDevicePathProtocolGuid in InstallHiiPages().)
>>
>> Not critical though, just simpler perhaps.
>>
>>> +  } else if (DtAcpiPref.Pref == DT_ACPI_SELECT_DT) {
>>> +//
>>> +// DT was selected: copy the blob into newly allocated memory and 
>>> install
>>> +// a reference to it as the FDT configuration table.
>>> +//
>>> +DtbCopy = AllocateCopyPool (DtbSize, Dtb);
>>> +if (DtbCopy == NULL) {
>>> +  return EFI_OUT_OF_RESOURCES;
>>> +}
>>> +Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DtbCopy);
>>> +if (EFI_ERROR (Status)) {
>>> +  DEBUG ((DEBUG_ERROR, "%a: failed to install FDT configuration 
>>> table\n",
>>> +__FUNCTION__));
>>> +  FreePool (DtbCopy);
>>> +  return Status;
>>> +}
>>
>> Looks good. The original DTB (found in the FV se

Re: [edk2] [PATCH] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Laszlo Ersek]

On 03/28/17 12:43, Laszlo Ersek wrote:
> Ard,
> 
> On 03/27/17 12:07, Ard Biesheuvel wrote:

[snip]

>> +/**
>> +  The entry point for DtPlatformDxe driver.
>> +
>> +  @param[in] ImageHandle The image handle of the driver.
>> +  @param[in] SystemTable The system table.
>> +
>> +  @retval EFI_ALREADY_STARTED The driver already exists in system.
>> +  @retval EFI_OUT_OF_RESOURCESFail to execute entry point due to lack of
>> +  resources.
>> +  @retval EFI_SUCCES  All the related protocols are installed on
>> +  the driver.
>> +
>> +**/
>> +EFI_STATUS
>> +EFIAPI
>> +DtPlatformDxeEntryPoint (
>> +  IN EFI_HANDLE   ImageHandle,
>> +  IN EFI_SYSTEM_TABLE *SystemTable
>> +  )
>> +{
>> +  EFI_STATUS  Status;
>> +  EFI_HANDLE  DriverHandle;
>> +  DT_ACPI_VARSTORE_DATA   DtAcpiPref;
>> +  UINTN   BufferSize;
>> +  VOID*Dtb;
>> +  UINTN   DtbSize;
>> +  VOID*DtbCopy;
>> +
>> +  //
>> +  // Check whether a DTB blob is included in the firmware image.
>> +  //
>> +  Dtb = NULL;
>> +  Status = GetSectionFromAnyFv (&gDtPlatformDefaultDtbFileGuid,
>> + EFI_SECTION_RAW, 0, &Dtb, &DtbSize);
>> +  if (EFI_ERROR (Status)) {
>> +DEBUG ((DEBUG_WARN, "%a: no DTB blob found, defaulting to ACPI\n",
>> +  __FUNCTION__));
>> +DtAcpiPref.Pref = DT_ACPI_SELECT_ACPI;
>> +  } else {
>> +//
>> +// Get the current ACPI/DT preference from the AcpiDtPref variable.
>> +//
> 
> The comment says "AcpiDtPref variable" (which corresponds to the name under 
> which the VFR also refers to the variable), but below the variable services 
> actually get a "DtAcpiPref" argument as variable name.
> 
> Please fix this inconsistency together with the other instances.
> 
>> +BufferSize = sizeof (DtAcpiPref);
>> +Status = gRT->GetVariable(L"DtAcpiPref", &gDtPlatformFormSetGuid, NULL,
>> +&BufferSize, &DtAcpiPref);
>> +if (EFI_ERROR (Status)) {
>> +  DEBUG ((DEBUG_WARN, "%a: no DT/ACPI preference found, defaulting to 
>> DT\n",
>> +__FUNCTION__));
>> +  DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
>> +}
>> +  }
>> +
>> +  if (!EFI_ERROR (Status) &&
>> +  DtAcpiPref.Pref != DT_ACPI_SELECT_ACPI &&
>> +  DtAcpiPref.Pref != DT_ACPI_SELECT_DT) {
>> +DEBUG ((DEBUG_WARN, "%a: illegal value for DtAcpiPref, defaulting to 
>> DT\n",
>> +  __FUNCTION__));
> 
> Personal request: please replace "illegal" with "invalid".
> 
>> +DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
>> +Status = EFI_INVALID_PARAMETER; // trigger setvar below
>> +  }
>> +
>> +  //
>> +  // Write the newly selected default value back to the variable store.
>> +  //
>> +  if (EFI_ERROR (Status)) {
>> +Status = gRT->SetVariable(L"DtAcpiPref", &gDtPlatformFormSetGuid,
>> +EFI_VARIABLE_NON_VOLATILE | 
>> EFI_VARIABLE_BOOTSERVICE_ACCESS,
>> +sizeof (DtAcpiPref), &DtAcpiPref);
> 
> I suggest to use a macro for the variable name...
> 
>> +if (EFI_ERROR (Status)) {
>> +  return Status;
>> +}
>> +  }
>> +
>> +  if (DtAcpiPref.Pref == DT_ACPI_SELECT_ACPI) {
>> +//
>> +// ACPI was selected: install the gEdkiiPlatformHasAcpiGuid GUID as a
>> +// NULL protocol to unlock dispatch of ACPI related drivers.
>> +//
>> +DriverHandle = NULL;
>> +Status = gBS->InstallMultipleProtocolInterfaces (&DriverHandle,
>> +gEdkiiPlatformHasAcpiGuid, NULL, NULL);
>> +if (EFI_ERROR (Status)) {
>> +  DEBUG ((DEBUG_ERROR,
>> +"%a: failed to install gEdkiiPlatformHasAcpiGuid as a protocol\n",
>> +__FUNCTION__));
>> +  return Status;
>> +}
> 
> I think you don't need to create a new controller handle for 
> gEdkiiPlatformHasAcpiGuid; using ImageHandle should be fine.
> 
> (Same for gEfiDevicePathProtocolGuid in InstallHiiPages().)
> 
> Not critical though, just simpler perhaps.
> 
>> +  } else if (DtAcpiPref.Pref == DT_ACPI_SELECT_DT) {
>> +//
>> +// DT was selected: copy the blob into newly allocated memory and 
>> install
>> +// a reference to it as the FDT configuration table.
>> +//
>> +DtbCopy = AllocateCopyPool (DtbSize, Dtb);
>> +if (DtbCopy == NULL) {
>> +  return EFI_OUT_OF_RESOURCES;
>> +}
>> +Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DtbCopy);
>> +if (EFI_ERROR (Status)) {
>> +  DEBUG ((DEBUG_ERROR, "%a: failed to install FDT configuration 
>> table\n",
>> +__FUNCTION__));
>> +  FreePool (DtbCopy);
>> +  return Status;
>> +}
> 
> Looks good. The original DTB (found in the FV section) lives in flash, 
> generally speaking, right?
> 
>> +  } else {
>> +ASSERT (FALSE);
>> +  }
>> +
>> +  //
>> +  // No point in installing the HII pages if ACPI is the only de

Re: [edk2] [PATCH] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Ard Biesheuvel]

On 28 March 2017 at 11:43, Laszlo Ersek  wrote:
> Ard,
>
> On 03/27/17 12:07, Ard Biesheuvel wrote:
>> As a follow up to the changes proposed by Laszlo to make ACPI and DT
>> mutually exclusive on ArmVirtQemu, this patch proposes a DT platform
>> DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
>> or installs the FV embedded DTB binary as a configuration table under
>> the appropriate GUID, depending on a preference setting recorded as
>> a UEFI variable, and configurable via a HII screen. This is intended
>> for bare metal platforms.
>>
>> The DTB binary can be embedded in the firmware image by adding the
>> following to the platform .fdf file:
>>
>>   FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
>> SECTION RAW = SomePkg/path/to/foo.dtb
>>   }
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>
>> This depends on patch 4/12 of Laszlo's series
>> https://lists.01.org/pipermail/edk2-devel/2017-March/009004.html
>>
>> Note to Marcin: the setup page was only tested with the generic BDS, not
>> the Intel BDS. This shouldn't matter in practice, since they should both
>> implement the prerequisite protocols, but moving to the generic BDS is
>> probably a good idea regardless.
>>
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 211 
>> 
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  29 +++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  70 +++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
>>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  57 ++
>>  EmbeddedPkg/EmbeddedPkg.dec |   6 +
>>  EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
>>  EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
>>  8 files changed, 446 insertions(+)
>>
>
> Please consider adopting
>
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-10
>
> and setting the "diff.orderFile" knob in your edk2 tree accordingly -- it is 
> a lot easier to review a patch if the declarative changes (headers, VFRs, INF 
> / DEC / DSC files) come first, and the imperative changes (C code) comes 
> second. I think I'll reorder files in your patch for this response.
>
> (BTW can you double-check that all new files in this patch have CRLF line 
> terminators?)
>

Ah, apologies, I switched to my arm64 development box, but apparently
failed to carry over those .dotfiles

>> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
>> index 2c2cf41103c2..c0f24422dc12 100644
>> --- a/EmbeddedPkg/EmbeddedPkg.dec
>> +++ b/EmbeddedPkg/EmbeddedPkg.dec
>> @@ -56,6 +56,12 @@ [Guids.common]
>>gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
>> 0xAD, 0x3F, 0x71, 0x6D } }
>>gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 
>> 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } }
>>
>> +  # HII form set GUID for DtPlatformDxe driver
>> +  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 
>> 0xdf, 0xa4, 0x41, 0x5f, 0x55, 0x26 } }
>> +
>> +  # File GUID for default DTB image embedded in the firmware volume
>> +  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 
>> 0x1d, 0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
>> +
>>  [Protocols.common]
>>gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
>> 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
>>gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 
>> 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
>
> This hunk looks okay to me.
>
>> diff --git a/EmbeddedPkg/Include/Guid/DtPlatformFormSet.h 
>> b/EmbeddedPkg/Include/Guid/DtPlatformFormSet.h
>> new file mode 100644
>> index ..71e3e7ebf7f3
>> --- /dev/null
>> +++ b/EmbeddedPkg/Include/Guid/DtPlatformFormSet.h
>> @@ -0,0 +1,23 @@
>> +/** @file
>> +*
>> +*  Copyright (c) 2017, Linaro Limited. All rights reserved.
>> +*
>> +*  This program and the accompanying materials
>> +*  are licensed and made available under the terms and conditions of the 
>> BSD License
>> +*  which 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 __DT_PLATFORM_FORMSET_H__
>> +#define __DT_PLATFORM_FORMSET_H__
>> +
>> +#define DT_PLATFORM_FORMSET_GUID  \
>> +  { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 0xdf, 0xa4, 0x41, 0x5f, 0x55, 
>> 0x26 } }
>> +
>> +extern EFI_GUID gDtPlatformFormSetGuid;
>> +
>> +#endif
>>
>
> Also okay.
>
>
>> diff --git a/EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h 
>> b/EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h
>> new file mode 100644
>> i

Re: [edk2] [PATCH] EmbeddedPkg: add DT platform driver to select between DT and ACPI

[Laszlo Ersek]

Ard,

On 03/27/17 12:07, Ard Biesheuvel wrote:
> As a follow up to the changes proposed by Laszlo to make ACPI and DT
> mutually exclusive on ArmVirtQemu, this patch proposes a DT platform
> DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
> or installs the FV embedded DTB binary as a configuration table under
> the appropriate GUID, depending on a preference setting recorded as
> a UEFI variable, and configurable via a HII screen. This is intended
> for bare metal platforms.
> 
> The DTB binary can be embedded in the firmware image by adding the
> following to the platform .fdf file:
> 
>   FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
> SECTION RAW = SomePkg/path/to/foo.dtb
>   }
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
> 
> This depends on patch 4/12 of Laszlo's series
> https://lists.01.org/pipermail/edk2-devel/2017-March/009004.html
> 
> Note to Marcin: the setup page was only tested with the generic BDS, not
> the Intel BDS. This shouldn't matter in practice, since they should both
> implement the prerequisite protocols, but moving to the generic BDS is
> probably a good idea regardless.
> 
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 211 
> 
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.h   |  29 +++
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  70 +++
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.uni |  27 +++
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr |  57 ++
>  EmbeddedPkg/EmbeddedPkg.dec |   6 +
>  EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h |  23 +++
>  EmbeddedPkg/Include/Guid/DtPlatformFormSet.h|  23 +++
>  8 files changed, 446 insertions(+)
> 

Please consider adopting

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-10

and setting the "diff.orderFile" knob in your edk2 tree accordingly -- it is a 
lot easier to review a patch if the declarative changes (headers, VFRs, INF / 
DEC / DSC files) come first, and the imperative changes (C code) comes second. 
I think I'll reorder files in your patch for this response.

(BTW can you double-check that all new files in this patch have CRLF line 
terminators?)

> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> index 2c2cf41103c2..c0f24422dc12 100644
> --- a/EmbeddedPkg/EmbeddedPkg.dec
> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> @@ -56,6 +56,12 @@ [Guids.common]
>gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
> 0xAD, 0x3F, 0x71, 0x6D } }
>gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 
> 0x4e, 0xfb, 0x3e, 0x57 } }
>  
> +  # HII form set GUID for DtPlatformDxe driver
> +  gDtPlatformFormSetGuid = { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 0xdf, 
> 0xa4, 0x41, 0x5f, 0x55, 0x26 } }
> +
> +  # File GUID for default DTB image embedded in the firmware volume
> +  gDtPlatformDefaultDtbFileGuid = { 0x25462cda, 0x221f, 0x47df, { 0xac, 
> 0x1d, 0x25, 0x9c, 0xfa, 0xa4, 0xe3, 0x26 } }
> +
>  [Protocols.common]
>gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
> 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
>gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 
> 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }

This hunk looks okay to me.

> diff --git a/EmbeddedPkg/Include/Guid/DtPlatformFormSet.h 
> b/EmbeddedPkg/Include/Guid/DtPlatformFormSet.h
> new file mode 100644
> index ..71e3e7ebf7f3
> --- /dev/null
> +++ b/EmbeddedPkg/Include/Guid/DtPlatformFormSet.h
> @@ -0,0 +1,23 @@
> +/** @file
> +*
> +*  Copyright (c) 2017, Linaro Limited. All rights reserved.
> +*
> +*  This program and the accompanying materials
> +*  are licensed and made available under the terms and conditions of the BSD 
> License
> +*  which 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 __DT_PLATFORM_FORMSET_H__
> +#define __DT_PLATFORM_FORMSET_H__
> +
> +#define DT_PLATFORM_FORMSET_GUID  \
> +  { 0x2b7a240d, 0xd5ad, 0x4fd6, { 0xbe, 0x1c, 0xdf, 0xa4, 0x41, 0x5f, 0x55, 
> 0x26 } }
> +
> +extern EFI_GUID gDtPlatformFormSetGuid;
> +
> +#endif
> 

Also okay.


> diff --git a/EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h 
> b/EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h
> new file mode 100644
> index ..98099ae68d6d
> --- /dev/null
> +++ b/EmbeddedPkg/Include/Guid/DtPlatformDefaultDtbFile.h
> @@ -0,0 +1,23 @@
> +/** @file
> +*
> +*  Copyright (c) 2017, Linaro Limited. All rights reserved.
> +*
> +*  This program and the accompanying materials
> +*  are licensed 

[edk2] [Patch] BaseTools: tools_def.txt to append new option in VFRPP flag

[Yonghong Zhu]

tools_def.txt to append new option (/FI$(MODULE_NAME)ImgDefs.h) in VFRPP
flag.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Conf/tools_def.template | 172 +++---
 1 file changed, 86 insertions(+), 86 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index ab4f936..b537abe 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -802,11 +802,11 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
Files/CodeSourcery/Sourcery G
 *_VS2003_IA32_RC_PATH   = DEF(VS2003_BIN)\rc.exe
 
   *_VS2003_IA32_MAKE_FLAGS  = /nologo
   *_VS2003_IA32_APP_FLAGS   = /nologo /E /TC
   *_VS2003_IA32_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
-  *_VS2003_IA32_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+  *_VS2003_IA32_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h /FI$(MODULE_NAME)ImgDefs.h
   DEBUG_VS2003_IA32_CC_FLAGS= /nologo /c /WX /W4 /Gs32768 /Gy /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /GX- /Zi /Gm
 RELEASE_VS2003_IA32_CC_FLAGS= /nologo /c /WX /W4 /Gs32768 /Gy /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /GX-
 NOOPT_VS2003_IA32_CC_FLAGS  = /nologo /c /WX /W4 /Gs32768 /Gy /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /GX- /Zi /Gm /Od
 
   DEBUG_VS2003_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /coff /Cx /Zd /Zi
@@ -836,11 +836,11 @@ NOOPT_VS2003_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 *_VS2003_EBC_RC_PATH= DEF(VS2003_BIN)\rc.exe
 
 *_VS2003_EBC_MAKE_FLAGS = /nologo
 *_VS2003_EBC_PP_FLAGS   = /nologo /E /TC /FIAutoGen.h
 *_VS2003_EBC_CC_FLAGS   = /nologo /c /WX /W3 /FIAutoGen.h 
/D$(MODULE_ENTRY_POINT)=$(ARCH_ENTRY_POINT)
-*_VS2003_EBC_VFRPP_FLAGS= /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2003_EBC_VFRPP_FLAGS= /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h /FI$(MODULE_NAME)ImgDefs.h
 *_VS2003_EBC_SLINK_FLAGS= /lib /NOLOGO /MACHINE:EBC
 *_VS2003_EBC_DLINK_FLAGS= "C:\Program 
Files\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
 

 #
@@ -880,11 +880,11 @@ NOOPT_VS2003_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 
 
   *_VS2003xASL_IA32_MAKE_FLAGS  = /nologo
   *_VS2003xASL_IA32_APP_FLAGS   = /nologo /E /TC
   *_VS2003xASL_IA32_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
-  *_VS2003xASL_IA32_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+  *_VS2003xASL_IA32_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h /FI$(MODULE_NAME)ImgDefs.h
   DEBUG_VS2003xASL_IA32_CC_FLAGS= /nologo /c /WX /W4 /Gs32768 /Gy /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /GX- /Zi /Gm
 RELEASE_VS2003xASL_IA32_CC_FLAGS= /nologo /c /WX /W4 /Gs32768 /Gy /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /GX-
 NOOPT_VS2003xASL_IA32_CC_FLAGS  = /nologo /c /WX /W4 /Gs32768 /Gy /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /GX- /Zi /Gm /Od
 
   DEBUG_VS2003xASL_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /coff /Cx /Zd /Zi
@@ -914,11 +914,11 @@ NOOPT_VS2003xASL_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OP
 *_VS2003xASL_EBC_RC_PATH= DEF(VS2003_BIN)\rc.exe
 
 *_VS2003xASL_EBC_MAKE_FLAGS = /nologo
 *_VS2003xASL_EBC_PP_FLAGS   = /nologo /E /TC /FIAutoGen.h
 *_VS2003xASL_EBC_CC_FLAGS   = /nologo /c /WX /W3 /FIAutoGen.h 
/D$(MODULE_ENTRY_POINT)=$(ARCH_ENTRY_POINT)
-*_VS2003xASL_EBC_VFRPP_FLAGS= /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2003xASL_EBC_VFRPP_FLAGS= /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h /FI$(MODULE_NAME)ImgDefs.h
 *_VS2003xASL_EBC_SLINK_FLAGS= /lib /NOLOGO /MACHINE:EBC
 *_VS2003xASL_EBC_DLINK_FLAGS= "C:\Program 
Files\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
 

 # Microsoft Visual Studio 2005
@@ -934,11 +934,11 @@ NOOPT_VS2003xASL_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OP
 *_VS2005_*_RC_PATH= DEF(VS2005_BIN)\rc.exe
 
 *_VS2005_*_SLINK_FLAGS= /NOLOGO /LTCG
 *_VS2005_*_APP_FLAGS  = /nologo /E /TC
 *_VS2005_*_PP_FLAGS   = /nologo /E /TC /FIAutoGen.h
-*_VS2005_*_VFRPP_FLAGS= /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.

[edk2] [Patch] BaseTools: Update Pkcs7 and RSA2048 tool with shell=True

[Yonghong Zhu]

Pkcs7Sign, Rsa2048Sha256Sign and Rsa2048Sha256GenerateKeys doesn't work
on Linux. It needs to be changed with shell=True.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py  | 4 ++--
 .../Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256GenerateKeys.py| 6 +++---
 BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py  | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py 
b/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
index 6412587..ef79f80 100644
--- a/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
+++ b/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
@@ -201,11 +201,11 @@ if __name__ == '__main__':
 FullInputFileBuffer = struct.pack(format, args.InputFileBuffer, 
args.MonotonicCountValue)
 
 #
 # Sign the input file using the specified private key and capture 
signature from STDOUT
 #
-Process = subprocess.Popen('%s smime -sign -binary -signer "%s" -outform 
DER -md sha256 -certfile "%s"' % (OpenSslCommand, 
args.SignerPrivateCertFileName, args.OtherPublicCertFileName), 
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+Process = subprocess.Popen('%s smime -sign -binary -signer "%s" -outform 
DER -md sha256 -certfile "%s"' % (OpenSslCommand, 
args.SignerPrivateCertFileName, args.OtherPublicCertFileName), 
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, 
shell=True)
 Signature = Process.communicate(input=FullInputFileBuffer)[0]
 if Process.returncode <> 0:
   sys.exit(Process.returncode)
 
 #
@@ -270,11 +270,11 @@ if __name__ == '__main__':
 open(args.OutputFileName, 'wb').write(FullInputFileBuffer)
 
 #
 # Verify signature
 #
-Process = subprocess.Popen('%s smime -verify -inform DER -content %s 
-CAfile %s' % (OpenSslCommand, args.OutputFileName, 
args.TrustedPublicCertFileName), stdin=subprocess.PIPE, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
+Process = subprocess.Popen('%s smime -verify -inform DER -content %s 
-CAfile %s' % (OpenSslCommand, args.OutputFileName, 
args.TrustedPublicCertFileName), stdin=subprocess.PIPE, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE, shell=True)
 Process.communicate(input=args.SignatureBuffer)[0]
 if Process.returncode <> 0:
   print 'ERROR: Verification failed'
   os.remove (args.OutputFileName)
   sys.exit(Process.returncode)
diff --git 
a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256GenerateKeys.py 
b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256GenerateKeys.py
index 2dd6c20..df2d989 100644
--- a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256GenerateKeys.py
+++ b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256GenerateKeys.py
@@ -96,11 +96,11 @@ if __name__ == '__main__':
   Item.close()
 
   #
   # Generate private key and save it to output file in a PEM file format
   #
-  Process = subprocess.Popen('%s genrsa -out %s 2048' % (OpenSslCommand, 
Item.name), stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+  Process = subprocess.Popen('%s genrsa -out %s 2048' % (OpenSslCommand, 
Item.name), stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
   Process.communicate()
   if Process.returncode <> 0:
 print 'ERROR: RSA 2048 key generation failed'
 sys.exit(Process.returncode)
   
@@ -118,11 +118,11 @@ if __name__ == '__main__':
   PublicKeyHash = ''
   for Item in args.PemFileName:
 #
 # Extract public key from private key into STDOUT
 #
-Process = subprocess.Popen('%s rsa -in %s -modulus -noout' % 
(OpenSslCommand, Item), stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+Process = subprocess.Popen('%s rsa -in %s -modulus -noout' % 
(OpenSslCommand, Item), stdout=subprocess.PIPE, stderr=subprocess.PIPE, 
shell=True)
 PublicKeyHexString = Process.communicate()[0].split('=')[1].strip()
 if Process.returncode <> 0:
   print 'ERROR: Unable to extract public key from private key'
   sys.exit(Process.returncode)
 PublicKey = ''
@@ -130,11 +130,11 @@ if __name__ == '__main__':
   PublicKey = PublicKey + chr(int(PublicKeyHexString[Index:Index + 2], 16))
 
 #
 # Generate SHA 256 hash of RSA 2048 bit public key into STDOUT
 #
-Process = subprocess.Popen('%s dgst -sha256 -binary' % (OpenSslCommand), 
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+Process = subprocess.Popen('%s dgst -sha256 -binary' % (OpenSslCommand), 
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, 
shell=True)
 Process.stdin.write (PublicKey)
 PublicKeyHash = PublicKeyHash + Process.communicate()[0]
 if Process.returncode <> 0:
   print 'ERROR: Unable to extract SHA 256 hash of public key'
   sys.exit(Process.returncode)
diff --git a/BaseTools/Source/Python/

Re: [edk2] [PATCH 00/12] OvmfPkg: Enable variable access in PEI

[Laszlo Ersek]

On 03/27/17 23:47, Jordan Justen wrote:
> On 2017-03-27 11:03:42, Laszlo Ersek wrote:
>> On 03/27/17 10:05, Jordan Justen wrote:
>>> web: https://github.com/jljusten/edk2/tree/pei-vars-v1
>>>
>>> git: https://github.com/jljusten/edk2.git pei-vars-v1
>>>
>>> This series moves flash detection into PEI to allow the PEI variable
>>> access drivers to run. If flash is writable, the PCDs are set to
>>> point at the flash memory. If flash is not writable, the PCDs are
>>> set to point at a memory buffer.
>>
>> Can you please state the use case for the latter option? That is,
>> when the PCDs are set to point at the memory buffer.
>>
>> In that case, the memory buffer is guaranteed to be empty (modulo
>> internal formatting that PlatformPei would do just-in-time), unless
>> the VM has just been rebooted within the same QEMU instance.
>>
>> In other words, clients of the r/o variable2 PPI will get false
>> results, most of the time -- if I understand correctly. After a fresh
>> boot (which is most of the boots), no variable will be found in the
>> PEI phase, even if the \NvVars file contains it, and the variable
>> services in DXE will later find it.
>>
>> ... I'm not sure if my understanding above is correct, but if it is,
>> then I think this feature only contributes to the confusing nature of
>> the memory-emulated variables.
>
> I think we should continue to support the memory vars, even if they
> have some obvious drawbacks.

I don't understand how you can call this "continued support" when Xen
(and any other similarly pflash-less virt host scenarios) will see zero
benefit from the increased complexity. The r/o variable2 PPI will be
available to them, and it will almost always lie to them.

Is that "continued support"? Is the availability of a lying PPI better
than the absence of a functional PPI? I'm out of arguments.

Anyway, I tested the series with the SMM_REQUIRE build -- you mentioned
in the blurb that you didn't test SMM --; there is a regression.
PlatformPei fails to detect flash:

> Loading PEIM at 0x0844B20 EntryPoint=0x0844D40 PlatformPei.efi
> Select Item: 0x0
> FW CFG Signature: 0x554D4551
> Select Item: 0x1
> FW CFG Revision: 0x3
> QemuFwCfg interface (DMA) is supported.
> QEMU Flash: Attempting flash detection at FFE00010
> QemuFlashDetected => FD behaves as ROM
> QemuFlashDetected => No
> Platform PEIM Loaded

the SMBASE relocation succeeds:

> Loading SMM driver at 0x0007FFA8000 EntryPoint=0x0007FFA9034 
> PiSmmCpuDxeSmm.efi
> SMRR Base: 0x7F80, SMRR Size: 0x80
> PcdCpuSmmCodeAccessCheckEnable = 1
> mAddressEncMask = 0x0
> SMRAM TileSize = 0x2000 (0x1000, 0x1000)
> SMRAM SaveState Buffer (0x7FF9A000, 0xE000)
> CPU[000]  APIC ID=  SMBASE=7FF92000  SaveState=7FFA1C00  Size=0400
> CPU[001]  APIC ID=0001  SMBASE=7FF94000  SaveState=7FFA3C00  Size=0400
> CPU[002]  APIC ID=0002  SMBASE=7FF96000  SaveState=7FFA5C00  Size=0400
> CPU[003]  APIC ID=0003  SMBASE=7FF98000  SaveState=7FFA7C00  Size=0400
> mXdSupported - 0x0
> One Semaphore Size= 0x40
> Total Semaphores Size = 0x840
> InstallProtocolInterface: [gEfiSmmConfigurationProtocolGuid] 7FFC2040
> SMM IPL registered SMM Entry Point address 7FFE099D
> SmmInstallProtocolInterface: [EfiSmmCpuProtocol] 7FFC2068
> SmmInstallProtocolInterface: [EfiSmmCpuServiceProtocol] 7FFC2084
> SMM S3 SMRAM Structure = 7F47DAD8
> SMM S3 Structure = 7F80
> SMM CPU Module exit from SMRAM with EFI_SUCCESS
> PageTable is 0!
> SMM IPL closed SMRAM window

and then FvbServicesSmm blows up due to the originally failed flash
detection:

> InstallProtocolInterface: [EfiLoadedImageProtocol] 7E9EEC10
> SmmInstallProtocolInterface: [EfiLoadedImageProtocol] 7FFDD47C
> Loading SMM driver at 0x0007FF5F000 EntryPoint=0x0007FF60034 
> FvbServicesSmm.efi
> ASSERT .../OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c(970): 
> !_gPcd_FixedAtBuild_PcdSmmSmramRequire

The reason for the failed flash detection, in PlatformPei, is that
PlatformPei does not run in System Management Mode. Therefore QEMU
denies it write access to the pflash chip.

Without the series applied, the flash detection (which involves a write)
only occurs in FvbServicesSmm, which is an SMM driver; it runs in System
Management Mode, so QEMU lets it write to the pflash chip.

NB, the assertion failure (the boot regression) is just one problem. The
real problem (concerning the feature itself) is that the failed dynamic
flash detection in PlatformPei will prevent the PEI phase, in the
SMM_REQUIRE build, from reading the actual pflash variable store.

In the SMM_REQUIRE build, the real variables in the pflash store *would
be* available for reading (via the r/o variable2 PPI), but PlatformPei
falls back to memory emulation, because it cannot successfully write the
pflash. That kind of defeats the entire feature.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/ed

[edk2] [PATCH 1/3] UefiCpuPkg/PiSmmCpuDxeSmm: Save SMM ranges info into global variables

[Jeff Fan]

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 44 --
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 ++-
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index d061482..bcdb498 100755
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -108,6 +108,12 @@ UINT64   mAddressEncMask = 0;
 //
 SPIN_LOCK*mConfigSmmCodeAccessCheckLock = NULL;
 
+//
+// Saved SMM ranges information
+//
+EFI_SMRAM_DESCRIPTOR *mSmmCpuSmramRanges;
+UINTNmSmmCpuSmramRangeCount;
+
 /**
   Initialize IDT to setup exception handlers for SMM.
 
@@ -971,8 +977,6 @@ FindSmramInfo (
   UINTN Size;
   EFI_SMM_ACCESS2_PROTOCOL  *SmmAccess;
   EFI_SMRAM_DESCRIPTOR  *CurrentSmramRange;
-  EFI_SMRAM_DESCRIPTOR  *SmramRanges;
-  UINTN SmramRangeCount;
   UINTN Index;
   UINT64MaxSize;
   BOOLEAN   Found;
@@ -990,31 +994,31 @@ FindSmramInfo (
   Status = SmmAccess->GetCapabilities (SmmAccess, &Size, NULL);
   ASSERT (Status == EFI_BUFFER_TOO_SMALL);
 
-  SmramRanges = (EFI_SMRAM_DESCRIPTOR *)AllocatePool (Size);
-  ASSERT (SmramRanges != NULL);
+  mSmmCpuSmramRanges = (EFI_SMRAM_DESCRIPTOR *)AllocatePool (Size);
+  ASSERT (mSmmCpuSmramRanges != NULL);
 
-  Status = SmmAccess->GetCapabilities (SmmAccess, &Size, SmramRanges);
+  Status = SmmAccess->GetCapabilities (SmmAccess, &Size, mSmmCpuSmramRanges);
   ASSERT_EFI_ERROR (Status);
 
-  SmramRangeCount = Size / sizeof (EFI_SMRAM_DESCRIPTOR);
+  mSmmCpuSmramRangeCount = Size / sizeof (EFI_SMRAM_DESCRIPTOR);
 
   //
   // Find the largest SMRAM range between 1MB and 4GB that is at least 256K - 
4K in size
   //
   CurrentSmramRange = NULL;
-  for (Index = 0, MaxSize = SIZE_256KB - EFI_PAGE_SIZE; Index < 
SmramRangeCount; Index++) {
+  for (Index = 0, MaxSize = SIZE_256KB - EFI_PAGE_SIZE; Index < 
mSmmCpuSmramRangeCount; Index++) {
 //
 // Skip any SMRAM region that is already allocated, needs testing, or 
needs ECC initialization
 //
-if ((SmramRanges[Index].RegionState & (EFI_ALLOCATED | EFI_NEEDS_TESTING | 
EFI_NEEDS_ECC_INITIALIZATION)) != 0) {
+if ((mSmmCpuSmramRanges[Index].RegionState & (EFI_ALLOCATED | 
EFI_NEEDS_TESTING | EFI_NEEDS_ECC_INITIALIZATION)) != 0) {
   continue;
 }
 
-if (SmramRanges[Index].CpuStart >= BASE_1MB) {
-  if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
BASE_4GB) {
-if (SmramRanges[Index].PhysicalSize >= MaxSize) {
-  MaxSize = SmramRanges[Index].PhysicalSize;
-  CurrentSmramRange = &SmramRanges[Index];
+if (mSmmCpuSmramRanges[Index].CpuStart >= BASE_1MB) {
+  if ((mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize) <= BASE_4GB) {
+if (mSmmCpuSmramRanges[Index].PhysicalSize >= MaxSize) {
+  MaxSize = mSmmCpuSmramRanges[Index].PhysicalSize;
+  CurrentSmramRange = &mSmmCpuSmramRanges[Index];
 }
   }
 }
@@ -1027,19 +1031,19 @@ FindSmramInfo (
 
   do {
 Found = FALSE;
-for (Index = 0; Index < SmramRangeCount; Index++) {
-  if (SmramRanges[Index].CpuStart < *SmrrBase && *SmrrBase == 
(SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize)) {
-*SmrrBase = (UINT32)SmramRanges[Index].CpuStart;
-*SmrrSize = (UINT32)(*SmrrSize + SmramRanges[Index].PhysicalSize);
+for (Index = 0; Index < mSmmCpuSmramRangeCount; Index++) {
+  if (mSmmCpuSmramRanges[Index].CpuStart < *SmrrBase &&
+  *SmrrBase == (mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize)) {
+*SmrrBase = (UINT32)mSmmCpuSmramRanges[Index].CpuStart;
+*SmrrSize = (UINT32)(*SmrrSize + 
mSmmCpuSmramRanges[Index].PhysicalSize);
 Found = TRUE;
-  } else if ((*SmrrBase + *SmrrSize) == SmramRanges[Index].CpuStart && 
SmramRanges[Index].PhysicalSize > 0) {
-*SmrrSize = (UINT32)(*SmrrSize + SmramRanges[Index].PhysicalSize);
+  } else if ((*SmrrBase + *SmrrSize) == mSmmCpuSmramRanges[Index].CpuStart 
&& mSmmCpuSmramRanges[Index].PhysicalSize > 0) {
+*SmrrSize = (UINT32)(*SmrrSize + 
mSmmCpuSmramRanges[Index].PhysicalSize);
 Found = TRUE;
   }
 }
   } while (Found);
 
-  FreePool (SmramRanges);
   DEBUG ((EFI_D_INFO, "SMRR Base: 0x%x, SMRR Size: 0x%x\n", *SmrrBase, 
*SmrrSize));
 }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
index 71af2f1..969eb47 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
@@

[edk2] [PATCH 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Update saved SMM ranges check in SmmProfile

[Jeff Fan]

SmmProfile feature required to protect all SMM ranges by structure
mProtectionMemRangeTemplate. This update is to add additonal save SMM ranges
into mProtectionMemRangeTemplate besides the range specified by
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 42 +-
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index 7125aec..2713b19 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -83,6 +83,12 @@ MEMORY_PROTECTION_RANGE mProtectionMemRangeTemplate[] = {
   {{0x, 0x},TRUE,TRUE},
 
   //
+  // SMRAM ranges not covered by 
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz (to be fixed in runtime).
+  // It is always present and instruction fetches are allowed.
+  // {{0x, 0x},TRUE,FALSE},
+  //
+
+  //
   // Future extended range could be added here.
   //
 
@@ -360,7 +366,7 @@ InitProtectedMemRange (
 {
   UINTNIndex;
   UINTNNumberOfDescriptors;
-  UINTNNumberOfMmioDescriptors;
+  UINTNNumberOfAddedDescriptors;
   UINTNNumberOfProtectRange;
   UINTNNumberOfSpliteRange;
   EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *MemorySpaceMap;
@@ -373,7 +379,7 @@ InitProtectedMemRange (
   UINT64   Low4KBPageSize;
 
   NumberOfDescriptors  = 0;
-  NumberOfMmioDescriptors  = 0;
+  NumberOfAddedDescriptors = mSmmCpuSmramRangeCount;
   NumberOfSpliteRange  = 0;
   MemorySpaceMap   = NULL;
 
@@ -386,12 +392,12 @@ InitProtectedMemRange (
);
   for (Index = 0; Index < NumberOfDescriptors; Index++) {
 if (MemorySpaceMap[Index].GcdMemoryType == EfiGcdMemoryTypeMemoryMappedIo) 
{
-  NumberOfMmioDescriptors++;
+  NumberOfAddedDescriptors++;
 }
   }
 
-  if (NumberOfMmioDescriptors != 0) {
-TotalSize = NumberOfMmioDescriptors * sizeof (MEMORY_PROTECTION_RANGE) + 
sizeof (mProtectionMemRangeTemplate);
+  if (NumberOfAddedDescriptors != 0) {
+TotalSize = NumberOfAddedDescriptors * sizeof (MEMORY_PROTECTION_RANGE) + 
sizeof (mProtectionMemRangeTemplate);
 mProtectionMemRange = (MEMORY_PROTECTION_RANGE *) AllocateZeroPool 
(TotalSize);
 ASSERT (mProtectionMemRange != NULL);
 mProtectionMemRangeCount = TotalSize / sizeof (MEMORY_PROTECTION_RANGE);
@@ -409,9 +415,27 @@ InitProtectedMemRange (
 ASSERT (mSplitMemRange != NULL);
 
 //
+// Create SMM ranges which are set to present and execution-enable.
+//
+NumberOfProtectRange = sizeof (mProtectionMemRangeTemplate) / sizeof 
(MEMORY_PROTECTION_RANGE);
+for (Index = 0; Index < mSmmCpuSmramRangeCount; Index++) {
+  if (mSmmCpuSmramRanges[Index].CpuStart >= 
mProtectionMemRange[0].Range.Base &&
+  mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize < mProtectionMemRange[0].Range.Top) {
+//
+// If the address have been already covered by 
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz
+//
+break;
+  }
+  mProtectionMemRange[NumberOfProtectRange].Range.Base = 
mSmmCpuSmramRanges[Index].CpuStart;
+  mProtectionMemRange[NumberOfProtectRange].Range.Top  = 
mSmmCpuSmramRanges[Index].CpuStart + mSmmCpuSmramRanges[Index].PhysicalSize;
+  mProtectionMemRange[NumberOfProtectRange].Present= TRUE;
+  mProtectionMemRange[NumberOfProtectRange].Nx = FALSE;
+  NumberOfProtectRange++;
+}
+
+//
 // Create MMIO ranges which are set to present and execution-disable.
 //
-NumberOfProtectRange= sizeof (mProtectionMemRangeTemplate) / sizeof 
(MEMORY_PROTECTION_RANGE);
 for (Index = 0; Index < NumberOfDescriptors; Index++) {
   if (MemorySpaceMap[Index].GcdMemoryType != 
EfiGcdMemoryTypeMemoryMappedIo) {
 continue;
@@ -422,6 +446,12 @@ InitProtectedMemRange (
   mProtectionMemRange[NumberOfProtectRange].Nx = TRUE;
   NumberOfProtectRange++;
 }
+
+//
+// Check and updated actual protected memory ranges count
+//
+ASSERT (NumberOfProtectRange <= mProtectionMemRangeCount);
+mProtectionMemRangeCount = NumberOfProtectRange;
   }
 
   //
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/3] UefiCpuPkg/PiSmmCpuDxeSmm: Add IsInSmmRanges() to check SMM range

[Jeff Fan]

Internal function IsInSmmRanges() is added t check SMM range by saved SMM ranges
beside by mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 36 +-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index 1b84e2c..7125aec 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
 Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
 This program and the accompanying materials
@@ -247,6 +247,33 @@ DebugExceptionHandler (
 }
 
 /**
+  Check if the input address is in SMM ranges.
+
+  @param[in]  Address   The input address.
+
+  @retval TRUE The input address is in SMM.
+  @retval FALSEThe input address is not in SMM.
+**/
+BOOLEAN
+IsInSmmRanges (
+  IN EFI_PHYSICAL_ADDRESS   Address
+  )
+{
+  UINTN  Index;
+
+  if ((Address < mCpuHotPlugData.SmrrBase) || (Address >= 
mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
+return TRUE;
+  }
+  for (Index = 0; Index < mSmmCpuSmramRangeCount; Index++) {
+if (Address >= mSmmCpuSmramRanges[Index].CpuStart &&
+Address < mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize) {
+  return TRUE;
+}
+  }
+  return FALSE;
+}
+
+/**
   Check if the memory address will be mapped by 4KB-page.
 
   @param  Address  The address of Memory.
@@ -261,7 +288,6 @@ IsAddressValid (
 {
   UINTN  Index;
 
-  *Nx = FALSE;
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 //
 // Check configuration
@@ -276,9 +302,9 @@ IsAddressValid (
 return FALSE;
 
   } else {
-if ((Address < mCpuHotPlugData.SmrrBase) ||
-(Address >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
-  *Nx = TRUE;
+*Nx = TRUE;
+if (IsInSmmRanges (Address)) {
+  *Nx = FALSE;
 }
 return TRUE;
   }
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/3] UefiCpuPkg/PiSmmCpuDxeSmm: Check all SMM ranges found

[Jeff Fan]

NX/SmmProfile feature required to protect all SMM ranges. This update is to
check additonal saved SMM ranges besides the range specified by
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 

Jeff Fan (3):
  UefiCpuPkg/PiSmmCpuDxeSmm: Save SMM ranges info into global variables
  UefiCpuPkg/PiSmmCpuDxeSmm: Add IsInSmmRanges() to check SMM range
  UefiCpuPkg/PiSmmCpuDxeSmm: Update saved SMM ranges check in SmmProfile

 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 44 +
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 78 +-
 3 files changed, 94 insertions(+), 32 deletions(-)

-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/3] UefiCpuPkg/PiSmmCpuDxeSmm: Add IsInSmmRanges() to check SMM range

[Jeff Fan]

Internal function IsInSmmRanges() is added t check SMM range by saved SMM ranges
beside by mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 36 +-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index 1b84e2c..7125aec 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
 Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
 This program and the accompanying materials
@@ -247,6 +247,33 @@ DebugExceptionHandler (
 }
 
 /**
+  Check if the input address is in SMM ranges.
+
+  @param[in]  Address   The input address.
+
+  @retval TRUE The input address is in SMM.
+  @retval FALSEThe input address is not in SMM.
+**/
+BOOLEAN
+IsInSmmRanges (
+  IN EFI_PHYSICAL_ADDRESS   Address
+  )
+{
+  UINTN  Index;
+
+  if ((Address < mCpuHotPlugData.SmrrBase) || (Address >= 
mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
+return TRUE;
+  }
+  for (Index = 0; Index < mSmmCpuSmramRangeCount; Index++) {
+if (Address >= mSmmCpuSmramRanges[Index].CpuStart &&
+Address < mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize) {
+  return TRUE;
+}
+  }
+  return FALSE;
+}
+
+/**
   Check if the memory address will be mapped by 4KB-page.
 
   @param  Address  The address of Memory.
@@ -261,7 +288,6 @@ IsAddressValid (
 {
   UINTN  Index;
 
-  *Nx = FALSE;
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 //
 // Check configuration
@@ -276,9 +302,9 @@ IsAddressValid (
 return FALSE;
 
   } else {
-if ((Address < mCpuHotPlugData.SmrrBase) ||
-(Address >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
-  *Nx = TRUE;
+*Nx = TRUE;
+if (IsInSmmRanges (Address)) {
+  *Nx = FALSE;
 }
 return TRUE;
   }
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/3] UefiCpuPkg/PiSmmCpuDxeSmm: Save SMM ranges info into global variables

[Jeff Fan]

NX/SmmProfile feature required to protect all SMM ranges. This update is
to check all saved SMM ranges by SMM ACCESS protocol besides the range
specified by mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 44 --
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 ++-
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index d061482..bcdb498 100755
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -108,6 +108,12 @@ UINT64   mAddressEncMask = 0;
 //
 SPIN_LOCK*mConfigSmmCodeAccessCheckLock = NULL;
 
+//
+// Saved SMM ranges information
+//
+EFI_SMRAM_DESCRIPTOR *mSmmCpuSmramRanges;
+UINTNmSmmCpuSmramRangeCount;
+
 /**
   Initialize IDT to setup exception handlers for SMM.
 
@@ -971,8 +977,6 @@ FindSmramInfo (
   UINTN Size;
   EFI_SMM_ACCESS2_PROTOCOL  *SmmAccess;
   EFI_SMRAM_DESCRIPTOR  *CurrentSmramRange;
-  EFI_SMRAM_DESCRIPTOR  *SmramRanges;
-  UINTN SmramRangeCount;
   UINTN Index;
   UINT64MaxSize;
   BOOLEAN   Found;
@@ -990,31 +994,31 @@ FindSmramInfo (
   Status = SmmAccess->GetCapabilities (SmmAccess, &Size, NULL);
   ASSERT (Status == EFI_BUFFER_TOO_SMALL);
 
-  SmramRanges = (EFI_SMRAM_DESCRIPTOR *)AllocatePool (Size);
-  ASSERT (SmramRanges != NULL);
+  mSmmCpuSmramRanges = (EFI_SMRAM_DESCRIPTOR *)AllocatePool (Size);
+  ASSERT (mSmmCpuSmramRanges != NULL);
 
-  Status = SmmAccess->GetCapabilities (SmmAccess, &Size, SmramRanges);
+  Status = SmmAccess->GetCapabilities (SmmAccess, &Size, mSmmCpuSmramRanges);
   ASSERT_EFI_ERROR (Status);
 
-  SmramRangeCount = Size / sizeof (EFI_SMRAM_DESCRIPTOR);
+  mSmmCpuSmramRangeCount = Size / sizeof (EFI_SMRAM_DESCRIPTOR);
 
   //
   // Find the largest SMRAM range between 1MB and 4GB that is at least 256K - 
4K in size
   //
   CurrentSmramRange = NULL;
-  for (Index = 0, MaxSize = SIZE_256KB - EFI_PAGE_SIZE; Index < 
SmramRangeCount; Index++) {
+  for (Index = 0, MaxSize = SIZE_256KB - EFI_PAGE_SIZE; Index < 
mSmmCpuSmramRangeCount; Index++) {
 //
 // Skip any SMRAM region that is already allocated, needs testing, or 
needs ECC initialization
 //
-if ((SmramRanges[Index].RegionState & (EFI_ALLOCATED | EFI_NEEDS_TESTING | 
EFI_NEEDS_ECC_INITIALIZATION)) != 0) {
+if ((mSmmCpuSmramRanges[Index].RegionState & (EFI_ALLOCATED | 
EFI_NEEDS_TESTING | EFI_NEEDS_ECC_INITIALIZATION)) != 0) {
   continue;
 }
 
-if (SmramRanges[Index].CpuStart >= BASE_1MB) {
-  if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
BASE_4GB) {
-if (SmramRanges[Index].PhysicalSize >= MaxSize) {
-  MaxSize = SmramRanges[Index].PhysicalSize;
-  CurrentSmramRange = &SmramRanges[Index];
+if (mSmmCpuSmramRanges[Index].CpuStart >= BASE_1MB) {
+  if ((mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize) <= BASE_4GB) {
+if (mSmmCpuSmramRanges[Index].PhysicalSize >= MaxSize) {
+  MaxSize = mSmmCpuSmramRanges[Index].PhysicalSize;
+  CurrentSmramRange = &mSmmCpuSmramRanges[Index];
 }
   }
 }
@@ -1027,19 +1031,19 @@ FindSmramInfo (
 
   do {
 Found = FALSE;
-for (Index = 0; Index < SmramRangeCount; Index++) {
-  if (SmramRanges[Index].CpuStart < *SmrrBase && *SmrrBase == 
(SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize)) {
-*SmrrBase = (UINT32)SmramRanges[Index].CpuStart;
-*SmrrSize = (UINT32)(*SmrrSize + SmramRanges[Index].PhysicalSize);
+for (Index = 0; Index < mSmmCpuSmramRangeCount; Index++) {
+  if (mSmmCpuSmramRanges[Index].CpuStart < *SmrrBase &&
+  *SmrrBase == (mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize)) {
+*SmrrBase = (UINT32)mSmmCpuSmramRanges[Index].CpuStart;
+*SmrrSize = (UINT32)(*SmrrSize + 
mSmmCpuSmramRanges[Index].PhysicalSize);
 Found = TRUE;
-  } else if ((*SmrrBase + *SmrrSize) == SmramRanges[Index].CpuStart && 
SmramRanges[Index].PhysicalSize > 0) {
-*SmrrSize = (UINT32)(*SmrrSize + SmramRanges[Index].PhysicalSize);
+  } else if ((*SmrrBase + *SmrrSize) == mSmmCpuSmramRanges[Index].CpuStart 
&& mSmmCpuSmramRanges[Index].PhysicalSize > 0) {
+*SmrrSize = (UINT32)(*SmrrSize + 
mSmmCpuSmramRanges[Index].PhysicalSize);
 Found = TRUE;
   }
 }
   } while (Found);
 
-  FreePool (SmramRanges);
   DEBUG ((EFI_D_INFO, "SMRR Base: 0x%x, SMRR Size: 0x%x\n", *SmrrBase, 
*SmrrSize));
 }
 
diff --git a/UefiCpuPkg/

[edk2] [PATCH 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Update saved SMM ranges check in SmmProfile

[Jeff Fan]

SmmProfile feature required to protect all SMM ranges by structure
mProtectionMemRangeTemplate. This update is to add additonal save SMM ranges
into mProtectionMemRangeTemplate besides the range specified by
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 42 +-
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index 7125aec..2713b19 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -83,6 +83,12 @@ MEMORY_PROTECTION_RANGE mProtectionMemRangeTemplate[] = {
   {{0x, 0x},TRUE,TRUE},
 
   //
+  // SMRAM ranges not covered by 
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz (to be fixed in runtime).
+  // It is always present and instruction fetches are allowed.
+  // {{0x, 0x},TRUE,FALSE},
+  //
+
+  //
   // Future extended range could be added here.
   //
 
@@ -360,7 +366,7 @@ InitProtectedMemRange (
 {
   UINTNIndex;
   UINTNNumberOfDescriptors;
-  UINTNNumberOfMmioDescriptors;
+  UINTNNumberOfAddedDescriptors;
   UINTNNumberOfProtectRange;
   UINTNNumberOfSpliteRange;
   EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *MemorySpaceMap;
@@ -373,7 +379,7 @@ InitProtectedMemRange (
   UINT64   Low4KBPageSize;
 
   NumberOfDescriptors  = 0;
-  NumberOfMmioDescriptors  = 0;
+  NumberOfAddedDescriptors = mSmmCpuSmramRangeCount;
   NumberOfSpliteRange  = 0;
   MemorySpaceMap   = NULL;
 
@@ -386,12 +392,12 @@ InitProtectedMemRange (
);
   for (Index = 0; Index < NumberOfDescriptors; Index++) {
 if (MemorySpaceMap[Index].GcdMemoryType == EfiGcdMemoryTypeMemoryMappedIo) 
{
-  NumberOfMmioDescriptors++;
+  NumberOfAddedDescriptors++;
 }
   }
 
-  if (NumberOfMmioDescriptors != 0) {
-TotalSize = NumberOfMmioDescriptors * sizeof (MEMORY_PROTECTION_RANGE) + 
sizeof (mProtectionMemRangeTemplate);
+  if (NumberOfAddedDescriptors != 0) {
+TotalSize = NumberOfAddedDescriptors * sizeof (MEMORY_PROTECTION_RANGE) + 
sizeof (mProtectionMemRangeTemplate);
 mProtectionMemRange = (MEMORY_PROTECTION_RANGE *) AllocateZeroPool 
(TotalSize);
 ASSERT (mProtectionMemRange != NULL);
 mProtectionMemRangeCount = TotalSize / sizeof (MEMORY_PROTECTION_RANGE);
@@ -409,9 +415,27 @@ InitProtectedMemRange (
 ASSERT (mSplitMemRange != NULL);
 
 //
+// Create SMM ranges which are set to present and execution-enable.
+//
+NumberOfProtectRange = sizeof (mProtectionMemRangeTemplate) / sizeof 
(MEMORY_PROTECTION_RANGE);
+for (Index = 0; Index < mSmmCpuSmramRangeCount; Index++) {
+  if (mSmmCpuSmramRanges[Index].CpuStart >= 
mProtectionMemRange[0].Range.Base &&
+  mSmmCpuSmramRanges[Index].CpuStart + 
mSmmCpuSmramRanges[Index].PhysicalSize < mProtectionMemRange[0].Range.Top) {
+//
+// If the address have been already covered by 
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz
+//
+break;
+  }
+  mProtectionMemRange[NumberOfProtectRange].Range.Base = 
mSmmCpuSmramRanges[Index].CpuStart;
+  mProtectionMemRange[NumberOfProtectRange].Range.Top  = 
mSmmCpuSmramRanges[Index].CpuStart + mSmmCpuSmramRanges[Index].PhysicalSize;
+  mProtectionMemRange[NumberOfProtectRange].Present= TRUE;
+  mProtectionMemRange[NumberOfProtectRange].Nx = FALSE;
+  NumberOfProtectRange++;
+}
+
+//
 // Create MMIO ranges which are set to present and execution-disable.
 //
-NumberOfProtectRange= sizeof (mProtectionMemRangeTemplate) / sizeof 
(MEMORY_PROTECTION_RANGE);
 for (Index = 0; Index < NumberOfDescriptors; Index++) {
   if (MemorySpaceMap[Index].GcdMemoryType != 
EfiGcdMemoryTypeMemoryMappedIo) {
 continue;
@@ -422,6 +446,12 @@ InitProtectedMemRange (
   mProtectionMemRange[NumberOfProtectRange].Nx = TRUE;
   NumberOfProtectRange++;
 }
+
+//
+// Check and updated actual protected memory ranges count
+//
+ASSERT (NumberOfProtectRange <= mProtectionMemRangeCount);
+mProtectionMemRangeCount = NumberOfProtectRange;
   }
 
   //
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/3] UefiCpuPkg/PiSmmCpuDxeSmm: Check all SMM ranges found

[Jeff Fan]

NX/SmmProfile feature required to protect all SMM ranges. This update is to
check additonal saved SMM ranges besides the range specified by
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 

Jeff Fan (3):
  UefiCpuPkg/PiSmmCpuDxeSmm: Save SMM ranges info into global variables
  UefiCpuPkg/PiSmmCpuDxeSmm: Add IsInSmmRanges() to check SMM range
  UefiCpuPkg/PiSmmCpuDxeSmm: Update saved SMM ranges check in SmmProfile

 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 44 +
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 78 +-
 3 files changed, 94 insertions(+), 32 deletions(-)

-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID

[Laszlo Ersek]

Star, Feng,

are you okay with this patch?

As we discussed under the v2 thread, BaseTools don't currently generate
EDKII_PLATFORM_HAS_ACPI_GUID style macros that are usable for
initializing static GUID variables, and GUID fields of static structures.

Therefore the

  MdeModulePkg/Include/Guid/PlatformHasAcpi.h

file in this patch adds functionality for which BaseTools have no
substitute.

So, we have the following two options:

(1) I can file a BZ for BaseTools to generate the above static
initializers, *but* for now, we go with this patch as-is, under
MdeModulePkg. If you agree with this, please respond to this patch with
your formal Reviewed-by.

(2) Or else, I will post a v4 of the series, moving this patch back
under ArmPkg, and updating the references in the rest of the patches.

Thanks,
Laszlo

On 03/24/17 23:38, Laszlo Ersek wrote:
> The presence of this GUID in the PPI database, and/or in the DXE protocol
> database (as dictated by the platform's needs in these firmware phases)
> implies that the platform provides the operating system with an ACPI-based
> hardware description. This is not necessarily exclusive with other types
> of hardware description (for example, a Device Tree-based one).
> 
> A platform PEIM and/or DXE driver is supposed to produce a single instance
> of the PPI and/or protocol (with NULL contents), if appropriate. The
> decision to produce the PPI and/or protocol is platform specific; for
> example, in the DXE phase, it could depend on an HII checkbox / underlying
> non-volatile UEFI variable.
> 
> In the DXE phase, the protocol is meant to be depended-upon by
> "MdeModulePkg/Universal/Acpi/AcpiTableDxe", indirectly:
> 
> * In the long term, interested platforms will establish this dependency by
>   hooking an (upcoming) NULL-class DepexLib instance into AcpiTableDxe in
>   their DSC files, pointing DepexLib's DEPEX through a FixedAtBuild PCD to
>   the GUID introduced here. (For the prerequisite BaseTools feature, refer
>   to ).
> 
> * In the short term, an interested platform may hook a private NULL-class
>   library instance (called e.g. "PlatformHasAcpiLib") into AcpiTableDxe.
>   Such a library instance would be a specialization of the above described
>   generic DepexLib, with the DEPEX open-coded on the GUID introduced here.
> 
> Either way, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled)
> EFI_ACPI_SDT_PROTOCOL dependent on the platform's dynamic decision to
> produce or not to produce a NULL protocol instance with this GUID.
> 
> In turn, other (platform and universal) DXE drivers that produce ACPI
> tables will wait for EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL, via
> DEPEX, protocol notify, or a simple gBS->LocateProtocol() in a "late
> enough" callback (such as Ready To Boot).
> 
> Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
> seen elsewhere in MdeModulePkg and SecurityPkg. In addition, an effort is
> made to avoid the phrase "AcpiPlatform", as that belongs to drivers /
> libraries that produce platform specific ACPI content (as opposed to
> deciding whether the entire firmware will have access to
> EFI_ACPI_TABLE_PROTOCOL, or any similar facilities in the PEI phase).
> 
> Cc: Ard Biesheuvel 
> Cc: Feng Tian 
> Cc: Leif Lindholm 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v3:
> - rename gEdkiiPlatformHasAcpiProtocolGuid to gEdkiiPlatformHasAcpiGuid
>   [Star]
> - update commit message and code comments to reflect possible use as a
>   PPI as well [Star]
> - move GUID from ArmPkg to MdeModulePkg [Leif, Ard]
> - split PlatformHasAcpiLib to a separate patch [Star]
> 
>  MdeModulePkg/MdeModulePkg.dec   |  3 ++
>  MdeModulePkg/Include/Guid/PlatformHasAcpi.h | 35 
>  2 files changed, 38 insertions(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 626e479f5e45..2d94881206d3 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -382,6 +382,9 @@ [Guids]
>gEdkiiNonDiscoverableUhciDeviceGuid = { 0xA8CDA0A2, 0x4F37, 0x4A1B, {0x8E, 
> 0x10, 0x8E, 0xF3, 0xCC, 0x3B, 0xF3, 0xA8 } }
>gEdkiiNonDiscoverableXhciDeviceGuid = { 0xB1BE0BC5, 0x6C28, 0x442D, {0xAA, 
> 0x37, 0x15, 0x1B, 0x42, 0x57, 0xBD, 0x78 } }
>  
> +  ## Include/Guid/PlatformHasAcpi.h
> +  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
> 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
> +
>  [Ppis]
>## Include/Ppi/AtaController.h
>gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 
> 0x7a, 0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
> diff --git a/MdeModulePkg/Include/Guid/PlatformHasAcpi.h 
> b/MdeModulePkg/Include/Guid/PlatformHasAcpi.h
> new file mode 100644
> index ..ad517821375d
> --- /dev/null
> +++ b/MdeModulePkg/Include/Guid/PlatformHasAcpi

Re: [edk2] [PATCH v2 00/11] Upgrade CryptoPkg to use the OpenSSL 1.1.0xx/stable release

[Ye, Ting]

Series Reviewed-by: Ye Ting 


-Original Message-
From: Long, Qin 
Sent: Thursday, March 23, 2017 9:19 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Wu, Jiaxin ; 
ler...@redhat.com; ard.biesheu...@linaro.org; g...@suse.com; 
ronald.c...@arm.com; moso@citrix.com; thomas.pal...@hpe.com
Subject: [PATCH v2 00/11] Upgrade CryptoPkg to use the OpenSSL 1.1.0xx/stable 
release

V2 Changes:
  1. Re-format patch series & handle some format fixes
 (as Laszlo Ersek's comments);
  2. Updated TlsLib Wrapper (as Thomas Palmer's comments);
  3. Add "ENGINESDIR" definition to support OpenSSL build if
 engine is enabled (as Moso Lee's comments)

(https://github.com/qloong/edk2/tree/dev-openssl-stable-v2)

Current EDKII-CryptoPkg is leveraging OpenSSL-1.0.2xx as the underlying 
cryptographic provider, which requires some extra patches
(EDKII-openssl-.patch) and installation scripts for EDKII build & usage.
The latest stable version of OpenSSL was upgraded to the 1.1.0 series of 
release, with lots of EDKII-specific patches integration, which make CryptoPkg 
possbile to remove all extra patch and scripts for more native build support.

This patch series is to update EDKII-CryptoPkg to support native building with 
the latest OpenSSL 1.1.0xx. (By now, the latest OpenSSL stable release is 
1.1.0e). Refer to "CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt" for the 
information about the version and source installation.

(NOTE: The extra build options for ARM/RVCT/XCODE were kept as before,
   and further optimizations were expected from community.)

Qin Long (11):
  CryptoPkg/OpensslLib: Update INF files to support OpenSSL-1.1.0x build
  CryptoPkg: Update .gitignore for OpenSSL source masking
  CryptoPkg/OpensslLib: Remove patch file and installation scripts.
  CryptoPkg/OpensslLib: Add new Perl script for file list generation.
  CryptoPkg/OpensslLib: Add new OpenSSL-HOWTO document.
  CryptoPkg: Fix handling of &strcmp function pointers
  CryptoPkg: Clean-up CRT Library Wrapper.
  CryptoPkg: Add extra build option to disable VS build warning
  CryptoPkg: Update HMAC Wrapper with opaque HMAC_CTX object.
  CryptoPkg: Update PK Cipher Wrappers work with opaque objects.
  CryptoPkg/TlsLib: Update TLS Wrapper to align with OpenSSL changes.

 CryptoPkg/.gitignore   |3 +-
 CryptoPkg/CryptoPkg.dec|8 +-
 CryptoPkg/Include/CrtLibSupport.h  |  193 ++
 CryptoPkg/Include/Library/BaseCryptLib.h   |   93 +-
 CryptoPkg/Include/OpenSslSupport.h |  286 ---
 CryptoPkg/Include/arpa/inet.h  |   16 -
 CryptoPkg/Include/assert.h |7 +-
 CryptoPkg/Include/ctype.h  |7 +-
 CryptoPkg/Include/dirent.h |   16 -
 CryptoPkg/Include/errno.h  |7 +-
 CryptoPkg/Include/internal/dso_conf.h  |0
 CryptoPkg/Include/limits.h |7 +-
 CryptoPkg/Include/malloc.h |   16 -
 CryptoPkg/Include/math.h   |   16 -
 CryptoPkg/Include/memory.h |7 +-
 CryptoPkg/Include/netdb.h  |   16 -
 CryptoPkg/Include/netinet/in.h |   16 -
 CryptoPkg/Include/openssl/opensslconf.h|  308 +++
 CryptoPkg/Include/sgtty.h  |   16 -
 CryptoPkg/Include/signal.h |   16 -
 CryptoPkg/Include/stdarg.h |7 +-
 CryptoPkg/Include/stddef.h |6 +-
 CryptoPkg/Include/stdio.h  |7 +-
 CryptoPkg/Include/stdlib.h |7 +-
 CryptoPkg/Include/string.h |7 +-
 CryptoPkg/Include/strings.h|6 +-
 CryptoPkg/Include/sys/ioctl.h  |   16 -
 CryptoPkg/Include/sys/param.h  |   16 -
 CryptoPkg/Include/sys/socket.h |   16 -
 CryptoPkg/Include/sys/stat.h   |   16 -
 CryptoPkg/Include/sys/time.h   |7 +-
 CryptoPkg/Include/sys/times.h  |   16 -
 CryptoPkg/Include/sys/types.h  |7 +-
 CryptoPkg/Include/sys/un.h |   16 -
 CryptoPkg/Include/syslog.h |6 +-
 CryptoPkg/Include/time.h   |6 +-
 CryptoPkg/Include/unistd.h |6 +-
 CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf|9 +-
 CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c |   77 +-
 .../Library/BaseCryptLib/Hmac/CryptHmacMd5Null.c   |   40 +-
 .../Library/BaseCryptLib/Hmac/CryptHmacSha1.c  |   75 +-
 .../Library/BaseCryptLib/Hmac/CryptHmacSha1Null.c  |   40 +-
 .../Library/BaseCryptLib/Hmac/CryptHmacSha256.c|   75 +-
 .../BaseCryptLib/Hmac/CryptHmacSha256Null.c|   40 +-
 Cryp

Re: [edk2] [RFC PATCH v2 04/10] OvmfPkg/BaseMemcryptSevLib: Add SEV helper library

[Laszlo Ersek]

On 03/27/17 20:44, Brijesh Singh wrote:
> On Mon, Mar 27, 2017 at 5:07 AM, Laszlo Ersek  wrote:
> 
>> On 03/27/17 11:19, Laszlo Ersek wrote:
>>> On 03/21/17 22:13, Brijesh Singh wrote:
>>
 +  Returns a boolean to indicate whether SEV is enabled
 +
 +  @retval TRUE   When SEV is active
 +  @retval FALSE  When SEV is not enabled
 +  **/
 +BOOLEAN
 +EFIAPI
 +MemEncryptSevIsEnabled (
 +  VOID
 +  );
>>>
>>> Would it make sense to call this library function in PlatformPei, rather
>>> than add a separate SevIsEnabled() function to it (in patch #3)? The
>>> implementations look nearly identical.
>>
>> I realize that earlier I seemingly suggested the opposite:
>>
>> http://mid.mail-archive.com/dd9436dc-415c-9fab-081c-
>> 39dd2cd71...@redhat.com
>>
>> http://mid.mail-archive.com/9193d837-6a78-b1c4-42c0-
>> 427fbc1f2...@redhat.com
>>
>> However, at that time, my understanding was that this library would only
>> be used in PlatformPei (hence the single user wouldn't justify the new
>> library instance). Now it seems that there are going to be several
>> client modules that check on SEV enablement. Is that right?
>>
>>
> 
> Yes, I do expect several client module link against this library to check
> whether the SEV is enabled.
> Are you okay if we link MemEncryptSevLib in PlatformPei and make use of
> MemEncryptSevIsEnabled()
> routine instead of having a local copy ? I was not sure which way to go
> hence I still have PlatformPei
> and QemuFwCfgPei using the local implementation of the same functions. My
> personal perference would
> be to link with MemEncryptSevLib instead of having local function. But as
> always I am open to suggestions.

I think the library function should be used (caching the CPUID detection
results) whenever we have writeable memory (PEI and onwards).

Thanks
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v2 09/10] OvmfPkg/QemuFwCfgLib: Add Secure Encrypted Virtualization (SEV) support

[Laszlo Ersek]

On 03/27/17 21:24, Brijesh Singh wrote:
> On Mon, Mar 27, 2017 at 5:19 AM, Laszlo Ersek  wrote:

>> - regarding InternalQemuFwCfgDmaBytes(): would it be possible to hook
>> the SEV-related tricks into the existent function, rather than
>> copy+modify the entire function as InternalQemuFwCfgSevDmaBytes()? It
>> seems to me that a conditional "prologue" and "epilogue" in
>> InternalQemuFwCfgDmaBytes() could do the trick.
>>
>>
> I wanted to reuse the existing function but I was not sure how do you
> wanted me to handle static allocation of "Access" variable inside
> the InternalQemuFwCfgDmaBytes()
> 
>  VOID
>  InternalQemuFwCfgDmaBytes (
>IN UINT32   Size,
>IN OUT VOID *Buffer OPTIONAL,
>IN UINT32   Control
>)
>  {
>volatile FW_CFG_DMA_ACCESS Access;
>UINT32 AccessHigh, AccessLow;
>UINT32 Status;
> 
> 
> The "Access" variable is statically allocated inside this function,

The storage duration of "Access" is not "static", it is "automatic".
(Put more colloquially, it is on the stack, it is not a global variable.)

But, I do understand the point; for the SEV case, you need it to be
dynamically allocated *and* exposed to the hypervisor, with
InternalQemuFwCfgSevDmaAllocateBuffer().

So here's my suggestion: in the following (suggested) list of patches:

- new interfaces in QemuFwCfgLibInternal.h
- implementation of new APIs for SEC instance
- implementation of new APIs for PEI instance
- implementation of new APIs for DXE instance
- call new APIs from common code

the last part should actually be two patches (so not 5 but 6 patches in
total).

First, please modify InternalQemuFwCfgDmaBytes() so that it works
through a pointer, but without other (functionality) changes:

  volatile FW_CFG_DMA_ACCESS LocalAccess;
  volatile FW_CFG_DMA_ACCESS *Access;

  Access = &LocalAccess;

Second, add the SEV-specific prologue / epilogue that initially set the
"Access" pointer differently, and finally free / unmap it.

> in case
> of SEV the Dma "Access" control variable need to be dynamically allocated
> because hypervisor read/writes data into Access->status.
> 
> I could convert Access into FW_CFG_DMA_ACCESS pointer for non SEV case and
> then integerate the SEV specific changes inside the same function.

Yes, that's the idea.

> 
> I was just not sure which approach is prefrered hence decided to create a
> new function for now and at least start the discussion.

Thank you.
Laszlo

> 
> 
> 
> 
>> ... From skimming this patch, I think those are the only
>> functionality-related comments I have at this point, beyond the remarks
>> I made elsewhere in this series (like: line length, DEBUG_* macros, and
>> so on). Please recheck all patches for those comments.
>>
>>
> I will revist all the patches and fix those DEBUG_* macros.
> 
> 
> 
>>>
>>> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
>> b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
>>> index ac05f4c..be8e945 100644
>>> --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
>>> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
>>> @@ -4,6 +4,7 @@
>>>
>>>Copyright (C) 2013, Red Hat, Inc.
>>>Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.
>>> +  Copyright (c) 2017, Advanced Micro Devices. All rights reserved.
>>>
>>>This program and the accompanying materials are licensed and made
>> available
>>>under the terms and conditions of the BSD License which accompanies
>> this
>>> @@ -14,14 +15,34 @@
>>>WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>>>  **/
>>>
>>> +#include "Uefi.h"
>>> +
>>> +#include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>
>>>  #include "QemuFwCfgLibInternal.h"
>>>
>>>  STATIC BOOLEAN mQemuFwCfgSupported = FALSE;
>>>  STATIC BOOLEAN mQemuFwCfgDmaSupported;
>>> +STATIC BOOLEAN mQemuFwCfgSevIsEnabled = FALSE;
>>> +
>>> +/**
>>> + Returns a boolean indicating whether the SEV is enabled
>>>
>>> + @retvalTRUESEV is enabled
>>> + @retvalFALSE   SEV is not enabled
>>> +**/
>>> +BOOLEAN
>>> +InternalQemuFwCfgSevIsEnabled (
>>> +  VOID
>>> +  )
>>> +{
>>> +  return mQemuFwCfgSevIsEnabled;
>>> +}
>>>
>>>  /**
>>>Returns a boolean indicating if the firmware configuration interface
>>> @@ -79,6 +100,9 @@ QemuFwCfgInitialize (
>>>  mQemuFwCfgDmaSupported = TRUE;
>>>  DEBUG ((DEBUG_INFO, "QemuFwCfg interface (DMA) is supported.\n"));
>>>}
>>> +
>>> +  mQemuFwCfgSevIsEnabled = MemEncryptSevIsEnabled ();
>>> +
>>>return RETURN_SUCCESS;
>>>  }
>>>
>>> @@ -114,3 +138,52 @@ InternalQemuFwCfgDmaIsAvailable (
>>>  {
>>>return mQemuFwCfgDmaSupported;
>>>  }
>>> +
>>> +/**
>>> + Allocate a bounce buffer for SEV DMA.
>>> +
>>
>> Please document that this function either succeeds or doesn't return.
>>
>>> +  @param[in] NumPage  Number of pages.
>>> +  @param[out]Buffer   Allocated DMA Buffer pointer
>>> +
>>> +**/
>>> +VOID
>>> +InternalQemuFwCfgSevDmaAllo

Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

[Laszlo Ersek]

On 03/28/17 07:25, Gao, Liming wrote:
> Ersek:
>   I don't want to block your patch. You can still check in Guid header file 
> if you think it is necessary. 

I don't want to check in without formal MdeModulePkg maintainer
approval. If I check in a patch without formal approval, that will only
lead to chaos. I don't want to circumvent the process; I want the
process to *work*.

If MdeModulePkg maintainers agree with my

  [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID

then they should please give their Reviewed-by for it.

If they disagree with it, they should please explain why.

The specific argument you raised, namely that a BaseTools utility
generates the necessary C language artifacts for GUID use, is not
precise. BaseTools generate *some* artifacts, but they do not generate a
macro that is usable for initializing a GUID object of static storage
duration (= global variable GUID, or a GUID field in a global variable
structure).

This is what the ISO C99 standard says:

  6.7.8 Initialization

  [...]

  Constraints

  [...]

  4 All the expressions in an initializer for an object that has static
storage duration shall be constant expressions or string literals.

  [...]

  16 Otherwise, the initializer for an object that has aggregate or
 union type shall be a brace-enclosed list of initializers for the
 elements or named members.

  [...]

  20 If the aggregate or union contains elements or members that are
 aggregates or unions, these rules apply recursively to the
 subaggregates or contained unions. [...]

This is the GUID type definition:

typedef struct {
  UINT32  Data1;
  UINT16  Data2;
  UINT16  Data3;
  UINT8   Data4[8];
} GUID;

For this structure, the above standardese implies that we have to
provide integer constant expressions in the initializer.

  6.6 Constant expressions

  [...]

  6 An /integer constant expression/ shall have integer type and shall
only have operands that are integer constants, enumeration
constants, character constants, /sizeof/ expressions whose results
are integer constants, and floating constants that are the
immediate operands of casts. Cast operators in an integer constant
expression shall only convert arithmetic types to integer types,
except as part of an operand to the /sizeof/ operator.

The end result is that "gEdkiiPlatformHasAcpiGuid" is not usable in such
contexts, but the EDKII_PLATFORM_HAS_ACPI_GUID macro is.


If you want, I can file a TianoCore feature request BZ for generating
such macros as well in BaseTools, but for now, I don't think it should
either block my patch noted above, or force me to drop the Guid/ header
file from the patch. Right now, the Guid/ header adds something that is
not available from BaseTools, and I wouldn't like to delay the v3 series
any longer.

Do you agree to the above method? I file a TianoCore Feature Request BZ
for BaseTools, and MdeModulePkg maintainers formally approve the v3
04/12 patch?


(Side point: I think the Guid/ header file has another benefit:
documentation. I don't think we can add the amount of documentation that
is acceptable in a standalone Guid/ header to an in-line comment in the
.DEC file. So, I think that the new rule for not adding Guid/ headers is
immature at this point -- and, worse, I don't recall an open
announcement or discussion about this rule, so that we could have raised
concerns before turning the proposal into an actual rule.)

Thanks
Laszlo

>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, March 28, 2017 1:32 AM
>> To: Ard Biesheuvel ; Gao, Liming 
>> 
>> Cc: Zeng, Star ; Kinney, Michael D 
>> ; af...@apple.com; Tian, Feng
>> ; edk2-devel-01 ; Leif 
>> Lindholm 
>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has 
>> ACPI Protocol, and plug-in library
>>
>> On 03/27/17 09:00, Ard Biesheuvel wrote:
>>> On 27 March 2017 at 03:42, Gao, Liming  wrote:
 Laszlo:
   On GUID header file, some header file are here, because they are added 
 before BaseTools supports it. Now, we allow not to add
>> header file if the header file only has GUID value definition.
>>>
>>> I have to agree with Laszlo here. The BaseTools support is incomplete,
>>> since it does not add a #define for the GUID to AutoGen.h. This makes
>>> it impossible to initialize static structures containing GUIDs, such
>>> as templates containing vendor device paths.
>>>
>>> For instance, the following
>>>
>>> typedef struct {
>>>   EFI_GUID foo;
>>> } TYPE;
>>>
>>> TYPE mFoo {
>>>   SOME_GUID
>>> };
>>>
>>> is not possible without a Guid/xxx.h include file containing a #define
>>> for SOME_GUID.
>>
>> I wonder if we can commit this series before end of April.
>>
>> Or is that too soon? End of May perhaps?
>>
>> The mind boggles.
>>
>> Laszlo
>>
>>>
   On GUID C MACRO, we suggest to use GuidCName in every C source code. So, 
 we don't suggest to add it.  As you know, some
>>

[edk2] [PATCH 1/2] MdeModulePkg/Tcp4Dxe: Fix unconditional window shrinking

[ate...@kraftway.ru]

Moving Right window edge to the left on sender side without additional
checks leads to the situation when sender assumes the receiver shrunk
its rcv buffer, when, in fact, it only reduced window size. This is a
TCP deadlock situation. Receiver ACKs proper segment, while sender
discards it for future ACK. Add check for negative usable window to
prevent erroneous window shrinking.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrey Tepin 
---
 MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c 
b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c
index 1000538..ea0766a 100644
--- a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c
+++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c
@@ -703,6 +703,7 @@ TcpInput (
   TCP_SEG *Seg;
   TCP_SEQNO   Right;
   TCP_SEQNO   Urg;
+  INT32   UsableWnd;
 
   NET_CHECK_SIGNATURE (Nbuf, NET_BUF_SIGNATURE);
 
@@ -1188,7 +1189,10 @@ TcpInput (
 
   if (TCP_SEQ_LT (Right, Tcb->SndNxt)) {
 
-Tcb->SndNxt = Right;
+UsableWnd = Tcb->SndUna + Tcb->SndWnd - Tcb->SndNxt;
+if (UsableWnd < 0) {
+  Tcb->SndNxt = Right;
+}
 
 if (Right == Tcb->SndUna) {
 
-- 
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking

[ate...@kraftway.ru]

Moving Right window edge to the left on sender side without additional
checks leads to the situation when sender assumes the receiver shrunk
its rcv buffer, when, in fact, it only reduced window size. This is a
TCP deadlock situation. Receiver ACKs proper segment, while sender
discards it for future ACK. Add check for negative usable window to
prevent erroneous window shrinking.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrey Tepin 
---
 NetworkPkg/TcpDxe/TcpInput.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/TcpDxe/TcpInput.c b/NetworkPkg/TcpDxe/TcpInput.c
index 04c8a82..11b3eb8 100644
--- a/NetworkPkg/TcpDxe/TcpInput.c
+++ b/NetworkPkg/TcpDxe/TcpInput.c
@@ -738,6 +738,7 @@ TcpInput (
   TCP_SEQNO   Right;
   TCP_SEQNO   Urg;
   UINT16  Checksum;
+  INT32   UsableWnd;
 
   ASSERT ((Version == IP_VERSION_4) || (Version == IP_VERSION_6));
 
@@ -1307,7 +1308,10 @@ TcpInput (
 
   if (TCP_SEQ_LT (Right, Tcb->SndNxt)) {
 
-Tcb->SndNxt = Right;
+UsableWnd = Tcb->SndUna + Tcb->SndWnd - Tcb->SndNxt;
+if (UsableWnd < 0) {
+  Tcb->SndNxt = Right;
+}
 
 if (Right == Tcb->SndUna) {
 
-- 
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel