[edk2-devel] [edk2-platforms] [PATCH v1 1/1] ClevoOpenBoardPkg/Features: Enable ThunderBolt

2019-08-30 Thread Sinha, Ankit
Add Thunderbolt ACPI table and enable feature PCD

Cc: Michael Kubacki 
Cc: Nate DeSimone 

Signed-off-by: Ankit Sinha 
---
 Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec|  1 +
 Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkgConfig.dsc   |  2 +-
 Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Gpe.asl  |  1 -
 Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Platform.asl |  1 +
 Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl | 55 

 5 files changed, 3 insertions(+), 57 deletions(-)

diff --git a/Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec 
b/Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec
index 28aedfef5988..9568d80b3aa9 100644
--- a/Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec
+++ b/Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec
@@ -20,6 +20,7 @@ PACKAGE_GUID  = D04CCA80-5F71-478D-9A26-72BC751D0106
 Include
 N1xxWU/Include
 Features/Tbt/Include
+Features/Tbt/AcpiTables
 
 [Guids]
 gBoardModuleTokenSpaceGuid=  {0x72d1fff7, 0xa42a, 0x4219, {0xb9, 
0x95, 0x5a, 0x67, 0x53, 0x6e, 0xa4, 0x2a}}
diff --git a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkgConfig.dsc 
b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkgConfig.dsc
index ea759776fb17..653fb0638e1d 100644
--- a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkgConfig.dsc
+++ b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkgConfig.dsc
@@ -48,7 +48,7 @@
   gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable|TRUE
 !endif
 
-  gBoardModuleTokenSpaceGuid.PcdTbtEnable|FALSE
+  gBoardModuleTokenSpaceGuid.PcdTbtEnable|TRUE
   #
   # More fine granularity control below:
   #
diff --git a/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Gpe.asl 
b/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Gpe.asl
index 8976c7a0ffcd..c95f4788e8a3 100644
--- a/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Gpe.asl
+++ b/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Gpe.asl
@@ -19,7 +19,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
   External(\_SB.PCI0.PEG1.HPME, MethodObj)
   External(\_SB.PCI0.PEG2.HPME, MethodObj)
   External(\_GPE.AL6F, MethodObj)
-  External(\_SB.THDR, MethodObj)
   External(\_GPE.P0L6, MethodObj)
   External(\_GPE.P1L6, MethodObj)
   External(\_GPE.P2L6, MethodObj)
diff --git 
a/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Platform.asl 
b/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Platform.asl
index 063093a08cb5..e5fa1de70035 100644
--- a/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Platform.asl
+++ b/Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Platform.asl
@@ -73,6 +73,7 @@ External(TBFF, MethodObj)
 External(FFTB, MethodObj)
 External(SXTB, MethodObj)
 
+include ("Tbt.asl")
 
 // Interrupt specific registers
 include("Itss.asl")
diff --git a/Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl 
b/Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl
index 2efe1a54f37e..e6cd45d49911 100644
--- a/Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl
+++ b/Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl
@@ -868,13 +868,6 @@ Scope(\_GPE)
 ADBG("Notify PEG2")
 Notify(\_SB.PCI0.PEG2,0)
   }
-#ifndef CPU_CFL
-  Case (4)
-  {
-ADBG("Notify PEG3")
-Notify(\_SB.PCI0.PEG3,0)
-  }
-#endif
 }
   }//Switch(ToInteger(TBSS)) // TBT Selector
 }//If(NOHP())
@@ -1606,54 +1599,6 @@ If(LAnd(LEqual(TBTS, 1),LOr(LEqual(RPS0, 
20),LEqual(RPS1, 20
   }//End of Scope(\_SB.PCI0.RP20)
 }
 
-If(LAnd(LEqual(TBTS, 1),LOr(LEqual(RPS0, 21),LEqual(RPS1, 21
-{
-  Scope(\_SB.PCI0.PEG0)
-  {
-Device(HRUS)// Host router Upstream port
-{
-  Name(_ADR, 0x)
-
-  Method(_RMV)
-  {
-Return(TARS)
-  } // end _RMV
-}
-  }//End of Scope(\_SB.PCI0.PEG0)
-}
-
-If(LAnd(LEqual(TBTS, 1),LOr(LEqual(RPS0, 22),LEqual(RPS1, 22
-{
-  Scope(\_SB.PCI0.PEG1)
-  {
-Device(HRUS)// Host router Upstream port
-{
-  Name(_ADR, 0x)
-
-  Method(_RMV)
-  {
-Return(TARS)
-  } // end _RMV
-}
-  }//End of Scope(\_SB.PCI0.PEG1)
-}
-
-If(LAnd(LEqual(TBTS, 1),LOr(LEqual(RPS0, 23),LEqual(RPS1, 23
-{
-  Scope(\_SB.PCI0.PEG2)
-  {
-Device(HRUS)// Host router Upstream port
-{
-  Name(_ADR, 0x)
-
-  Method(_RMV)
-  {
-Return(TARS)
-  } // end _RMV
-}
-  }//End of Scope(\_SB.PCI0.PEG2)
-}
-
 Scope(\_SB)
 {
 //
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46642): https://edk2.groups.io/g/devel/message/46642
Mute This Topic: https://groups.io/mt/33085196/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms] [PATCH v1 0/1] ClevoOpenBoardPkg/Features: Enable ThunderBolt

2019-08-30 Thread Sinha, Ankit
Add Thunderbolt ACPI table and enable feature PCD

Cc: Michael Kubacki 
Cc: Nate DeSimone 

 Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec|  1 +
 Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkgConfig.dsc   |  2 +-
 Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Gpe.asl  |  1 -
 Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/Platform.asl |  1 +
 Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl | 55 

 5 files changed, 3 insertions(+), 57 deletions(-)

-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46641): https://edk2.groups.io/g/devel/message/46641
Mute This Topic: https://groups.io/mt/33085187/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms] [PATCH v2 1/1] MinPlatformPkg/Acpi: MADT NMI default flag set to Edge-Triggered

2019-08-30 Thread Sinha, Ankit
1. Default APIC NMI structure in MADT changed to expose
   Level-Triggered interrupts.
2. x2APIC NMI structure won't be exposed to OS if x2APIC is not enabled.

Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 

Signed-off-by: Ankit Sinha 
---
 Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 54 
++--
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c 
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 5eb727929bfb..1b251ca2962d 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI Platform Driver
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -1049,7 +1049,7 @@ InstallMadtFromScratch (
   LocalApciNmiStruct.Type   = EFI_ACPI_4_0_LOCAL_APIC_NMI;
   LocalApciNmiStruct.Length = sizeof (EFI_ACPI_4_0_LOCAL_APIC_NMI_STRUCTURE);
   LocalApciNmiStruct.AcpiProcessorId = 0xFF;  // Applies to all processors
-  LocalApciNmiStruct.Flags   = 0x000D;// Flags - Level-tiggered, 
Active High
+  LocalApciNmiStruct.Flags   = 0x0005;// Flags - Edge-tiggered, 
Active High
   LocalApciNmiStruct.LocalApicLint   = 0x1;
 
   ASSERT (MadtStructsIndex < MaxMadtStructCount);
@@ -1066,24 +1066,26 @@ InstallMadtFromScratch (
   //
   // Build Local x2APIC NMI Structure
   //
-  LocalX2ApicNmiStruct.Type   = EFI_ACPI_4_0_LOCAL_X2APIC_NMI;
-  LocalX2ApicNmiStruct.Length = sizeof 
(EFI_ACPI_4_0_LOCAL_X2APIC_NMI_STRUCTURE);
-  LocalX2ApicNmiStruct.Flags  = 0x000D;// Flags - 
Level-tiggered, Active High
-  LocalX2ApicNmiStruct.AcpiProcessorUid = 0x;  // Applies to all 
processors
-  LocalX2ApicNmiStruct.LocalX2ApicLint  = 0x01;
-  LocalX2ApicNmiStruct.Reserved[0] = 0x00;
-  LocalX2ApicNmiStruct.Reserved[1] = 0x00;
-  LocalX2ApicNmiStruct.Reserved[2] = 0x00;
+  if (mX2ApicEnabled) {
+LocalX2ApicNmiStruct.Type   = EFI_ACPI_4_0_LOCAL_X2APIC_NMI;
+LocalX2ApicNmiStruct.Length = sizeof 
(EFI_ACPI_4_0_LOCAL_X2APIC_NMI_STRUCTURE);
+LocalX2ApicNmiStruct.Flags  = 0x000D;// Flags - 
Level-tiggered, Active High
+LocalX2ApicNmiStruct.AcpiProcessorUid = 0x;  // Applies to all 
processors
+LocalX2ApicNmiStruct.LocalX2ApicLint  = 0x01;
+LocalX2ApicNmiStruct.Reserved[0] = 0x00;
+LocalX2ApicNmiStruct.Reserved[1] = 0x00;
+LocalX2ApicNmiStruct.Reserved[2] = 0x00;
 
-  ASSERT (MadtStructsIndex < MaxMadtStructCount);
-  Status = CopyStructure (
-,
-(STRUCTURE_HEADER *) ,
-[MadtStructsIndex++]
-);
-  if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "CopyMadtStructure (x2APIC NMI) failed: %r\n", 
Status));
-goto Done;
+ASSERT (MadtStructsIndex < MaxMadtStructCount);
+Status = CopyStructure (
+  ,
+  (STRUCTURE_HEADER *) ,
+  [MadtStructsIndex++]
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "CopyMadtStructure (x2APIC NMI) failed: %r\n", 
Status));
+  goto Done;
+}
   }
 
   //
@@ -1167,7 +1169,7 @@ InstallMcfgFromScratch (
   //
   // Set MCFG table "Length" field based on the number of PCIe segments 
enumerated so far
   //
-  McfgTable->Header.Length = (UINT32)(sizeof 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER) + 
+  McfgTable->Header.Length = (UINT32)(sizeof 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER) +
   sizeof 
(EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_ADDRESS_ALLOCATION_STRUCTURE)
 * SegmentCount);
 
   Segment = (VOID *)(McfgTable + 1);
@@ -1329,11 +1331,11 @@ PlatformUpdateTables (
 HpetCapabilities.Uint64  = HpetCapabilitiesData;
 HpetCapabilitiesData = MmioRead32 (HpetBaseAddress + 
HPET_GENERAL_CAPABILITIES_ID_OFFSET + 4);
 HpetCapabilities.Uint64 |= LShiftU64 (HpetCapabilitiesData, 32);
-HpetBlockId.Bits.Revision   = HpetCapabilities.Bits.Revision;
-HpetBlockId.Bits.NumberOfTimers = HpetCapabilities.Bits.NumberOfTimers;
-HpetBlockId.Bits.CounterSize= HpetCapabilities.Bits.CounterSize;
-HpetBlockId.Bits.Reserved   = 0;
-HpetBlockId.Bits.LegacyRoute= HpetCapabilities.Bits.LegacyRoute;
+HpetBlockId.Bits.Revision   = HpetCapabilities.Bits.Revision;
+HpetBlockId.Bits.NumberOfTimers = HpetCapabilities.Bits.NumberOfTimers;
+HpetBlockId.Bits.CounterSize= HpetCapabilities.Bits.CounterSize;
+HpetBlockId.Bits.Reserved   = 0;
+HpetBlockId.Bits.LegacyRoute= HpetCapabilities.Bits.LegacyRoute;
 HpetBlockId.Bits.VendorId   = HpetCapabilities.Bits.VendorId;
 HpetTable->EventTimerBlockId= HpetBlockId.Uint32;
 HpetTable->MainCounterMinimumClockTickInPeriodicMode = 

[edk2-devel] [edk2-platforms PATCH v1 1/1] MinPlatformPkg/Acpi: MADT NMI default flag set to Edge-Triggered

2019-08-30 Thread Sinha, Ankit
1. Default APIC NMI structure in MADT changed to expose
   Level-Triggered interrupts.
2. x2APIC NMI structure won't be exposed to OS if x2APIC is not enabled.

Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 

Signed-off-by: Ankit Sinha 
---
 Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 52 
++--
 1 file changed, 27 insertions(+), 25 deletions(-)

diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c 
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 5eb727929bfb..9c8e9f22e1ba 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -1049,7 +1049,7 @@ InstallMadtFromScratch (
   LocalApciNmiStruct.Type   = EFI_ACPI_4_0_LOCAL_APIC_NMI;
   LocalApciNmiStruct.Length = sizeof (EFI_ACPI_4_0_LOCAL_APIC_NMI_STRUCTURE);
   LocalApciNmiStruct.AcpiProcessorId = 0xFF;  // Applies to all processors
-  LocalApciNmiStruct.Flags   = 0x000D;// Flags - Level-tiggered, 
Active High
+  LocalApciNmiStruct.Flags   = 0x0005;// Flags - Edge-tiggered, 
Active High
   LocalApciNmiStruct.LocalApicLint   = 0x1;
 
   ASSERT (MadtStructsIndex < MaxMadtStructCount);
@@ -1066,24 +1066,26 @@ InstallMadtFromScratch (
   //
   // Build Local x2APIC NMI Structure
   //
-  LocalX2ApicNmiStruct.Type   = EFI_ACPI_4_0_LOCAL_X2APIC_NMI;
-  LocalX2ApicNmiStruct.Length = sizeof 
(EFI_ACPI_4_0_LOCAL_X2APIC_NMI_STRUCTURE);
-  LocalX2ApicNmiStruct.Flags  = 0x000D;// Flags - 
Level-tiggered, Active High
-  LocalX2ApicNmiStruct.AcpiProcessorUid = 0x;  // Applies to all 
processors
-  LocalX2ApicNmiStruct.LocalX2ApicLint  = 0x01;
-  LocalX2ApicNmiStruct.Reserved[0] = 0x00;
-  LocalX2ApicNmiStruct.Reserved[1] = 0x00;
-  LocalX2ApicNmiStruct.Reserved[2] = 0x00;
+  if (mX2ApicEnabled) {
+LocalX2ApicNmiStruct.Type   = EFI_ACPI_4_0_LOCAL_X2APIC_NMI;
+LocalX2ApicNmiStruct.Length = sizeof 
(EFI_ACPI_4_0_LOCAL_X2APIC_NMI_STRUCTURE);
+LocalX2ApicNmiStruct.Flags  = 0x000D;// Flags - 
Level-tiggered, Active High
+LocalX2ApicNmiStruct.AcpiProcessorUid = 0x;  // Applies to all 
processors
+LocalX2ApicNmiStruct.LocalX2ApicLint  = 0x01;
+LocalX2ApicNmiStruct.Reserved[0] = 0x00;
+LocalX2ApicNmiStruct.Reserved[1] = 0x00;
+LocalX2ApicNmiStruct.Reserved[2] = 0x00;
 
-  ASSERT (MadtStructsIndex < MaxMadtStructCount);
-  Status = CopyStructure (
-,
-(STRUCTURE_HEADER *) ,
-[MadtStructsIndex++]
-);
-  if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "CopyMadtStructure (x2APIC NMI) failed: %r\n", 
Status));
-goto Done;
+ASSERT (MadtStructsIndex < MaxMadtStructCount);
+Status = CopyStructure (
+  ,
+  (STRUCTURE_HEADER *) ,
+  [MadtStructsIndex++]
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "CopyMadtStructure (x2APIC NMI) failed: %r\n", 
Status));
+  goto Done;
+}
   }
 
   //
@@ -1167,7 +1169,7 @@ InstallMcfgFromScratch (
   //
   // Set MCFG table "Length" field based on the number of PCIe segments 
enumerated so far
   //
-  McfgTable->Header.Length = (UINT32)(sizeof 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER) + 
+  McfgTable->Header.Length = (UINT32)(sizeof 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER) +
   sizeof 
(EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_ADDRESS_ALLOCATION_STRUCTURE)
 * SegmentCount);
 
   Segment = (VOID *)(McfgTable + 1);
@@ -1329,11 +1331,11 @@ PlatformUpdateTables (
 HpetCapabilities.Uint64  = HpetCapabilitiesData;
 HpetCapabilitiesData = MmioRead32 (HpetBaseAddress + 
HPET_GENERAL_CAPABILITIES_ID_OFFSET + 4);
 HpetCapabilities.Uint64 |= LShiftU64 (HpetCapabilitiesData, 32);
-HpetBlockId.Bits.Revision   = HpetCapabilities.Bits.Revision;
-HpetBlockId.Bits.NumberOfTimers = HpetCapabilities.Bits.NumberOfTimers;
-HpetBlockId.Bits.CounterSize= HpetCapabilities.Bits.CounterSize;
-HpetBlockId.Bits.Reserved   = 0;
-HpetBlockId.Bits.LegacyRoute= HpetCapabilities.Bits.LegacyRoute;
+HpetBlockId.Bits.Revision   = HpetCapabilities.Bits.Revision;
+HpetBlockId.Bits.NumberOfTimers = HpetCapabilities.Bits.NumberOfTimers;
+HpetBlockId.Bits.CounterSize= HpetCapabilities.Bits.CounterSize;
+HpetBlockId.Bits.Reserved   = 0;
+HpetBlockId.Bits.LegacyRoute= HpetCapabilities.Bits.LegacyRoute;
 HpetBlockId.Bits.VendorId   = HpetCapabilities.Bits.VendorId;
 HpetTable->EventTimerBlockId= HpetBlockId.Uint32;
 HpetTable->MainCounterMinimumClockTickInPeriodicMode = 
(UINT16)HpetCapabilities.Bits.CounterClockPeriod;
@@ -1459,7 +1461,7 @@ UpdateLocalTable (
 
   for (Index = 0; Index < sizeof(mLocalTable)/sizeof(mLocalTable[0]); Index++) 
{
 CurrentTable = mLocalTable[Index];
-  
+
 PlatformUpdateTables 

[edk2-devel] [edk2-platforms PATCH v1 0/1] MinPlatformPkg/Acpi: MADT NMI default flag set to Edge-Triggered

2019-08-30 Thread Sinha, Ankit
1. Default APIC NMI structure in MADT changed to expose Level-Triggered 
interrupts.
2. x2APIC NMI structure won't be exposed to OS if x2APIC is not enabled.

Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 

Ankit Sinha (1):
  MinPlatformPkg/Acpi: MADT NMI default flag set to Edge-Triggered

 Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 52 
++--
 1 file changed, 27 insertions(+), 25 deletions(-)

-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46638): https://edk2.groups.io/g/devel/message/46638
Mute This Topic: https://groups.io/mt/33084915/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms PATCH v4 6/7] Platform/Intel: Add build option for SIMICS QSP Platform

2019-08-30 Thread David Wei
Add build option in build script for SIMICS QSP Platform

Add Maintainers of Simics QSP related packages

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 Maintainers.txt  | 12 
 Platform/Intel/build.cfg |  2 ++
 Platform/Intel/build_bios.py |  3 +++
 3 files changed, 17 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index b16432bf87..90eb3c3dd0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -103,6 +103,10 @@ M: Chasel Chiu 
 M: Michael Kubacki 
 M: Nate DeSimone 
 
+Platform/Intel/SimicsOpenBoardPkg
+M: Wei David Y 
+M: Agyeman Prince 
+
 Platform/Intel/Tools
 M: Bob Feng 
 M: Liming Gao 
@@ -155,6 +159,14 @@ M: Gillispie, Thad 
 M: Bu, Daocheng 
 M: Oram, Isaac W 
 
+Silicon/Intel/SimicsX58SktPkg
+M: Wei David Y 
+M: Agyeman Prince 
+
+Silicon/Intel/SimicsIch10Pkg
+M: Wei David Y 
+M: Agyeman Prince 
+
 Silicon/Intel/Tools
 M: Bob Feng 
 M: Liming Gao 
diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index b6d32ada49..75cb446aa5 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -11,6 +11,7 @@ WORKSPACE =
 WORKSPACE_FSP_BIN = FSP
 EDK_TOOLS_BIN = edk2-BaseTools-win32
 EDK_BASETOOLS = BaseTools
+WORKSPACE_DRIVERS = edk2-platforms/Drivers
 WORKSPACE_PLATFORM = edk2-platforms/Platform/Intel
 WORKSPACE_SILICON = edk2-platforms/Silicon/Intel
 WORKSPACE_PLATFORM_BIN =
@@ -52,6 +53,7 @@ NUMBER_OF_PROCESSORS = 0
 [PLATFORMS]
 # board_name = path_to_board_build_config.cfg
 BoardMtOlympus = PurleyOpenBoardPkg/BoardMtOlympus/build_config.cfg
+BoardX58Ich10 = SimicsOpenBoardPkg/BoardX58Ich10/build_config.cfg
 KabylakeRvp3 = KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
 N1xxWU = ClevoOpenBoardPkg/N1xxWU/build_config.cfg
 WhiskeylakeURvp = WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
diff --git a/Platform/Intel/build_bios.py b/Platform/Intel/build_bios.py
index 9152670dcb..46285df19a 100644
--- a/Platform/Intel/build_bios.py
+++ b/Platform/Intel/build_bios.py
@@ -104,6 +104,8 @@ def pre_build(build_config, build_type="DEBUG", 
silent=False, toolchain=None):
 config["WORKSPACE_PLATFORM"])
 config["WORKSPACE_SILICON"] = os.path.join(config["WORKSPACE"],
config["WORKSPACE_SILICON"])
+config["WORKSPACE_DRIVERS"] = os.path.join(config["WORKSPACE"],
+   config["WORKSPACE_DRIVERS"])
 config["WORKSPACE_PLATFORM_BIN"] = \
 os.path.join(config["WORKSPACE"], config["WORKSPACE_PLATFORM_BIN"])
 config["WORKSPACE_SILICON_BIN"] = \
@@ -115,6 +117,7 @@ def pre_build(build_config, build_type="DEBUG", 
silent=False, toolchain=None):
 config["PACKAGES_PATH"] = config["WORKSPACE_PLATFORM"]
 config["PACKAGES_PATH"] += os.pathsep + config["WORKSPACE_SILICON"]
 config["PACKAGES_PATH"] += os.pathsep + config["WORKSPACE_SILICON_BIN"]
+config["PACKAGES_PATH"] += os.pathsep + config["WORKSPACE_DRIVERS"]
 config["PACKAGES_PATH"] += os.pathsep + \
 os.path.join(config["WORKSPACE"], "FSP")
 config["PACKAGES_PATH"] += os.pathsep + \
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46635): https://edk2.groups.io/g/devel/message/46635
Mute This Topic: https://groups.io/mt/33084493/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms PATCH v4 1/7] SimicsX58SktPkg: Add CPU Pkg for SimicsX58

2019-08-30 Thread David Wei
Add CPU Pkg for SimicsX58. It is added for simics QSP project support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c | 148 +
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.c  | 346 +
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.c | 200 
 .../Include/Register/X58SmramSaveStateMap.h| 178 +++
 Silicon/Intel/SimicsX58SktPkg/SktPkg.dec   |  37 +++
 Silicon/Intel/SimicsX58SktPkg/SktPkgPei.dsc|  14 +
 .../Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf |   9 +
 .../Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf  |  10 +
 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf|  16 +
 .../Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf   |  14 +
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf   |  54 
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf|  65 
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.h |  82 +
 13 files changed, 1173 insertions(+)
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.c
 create mode 100644 
Silicon/Intel/SimicsX58SktPkg/Include/Register/X58SmramSaveStateMap.h
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPkg.dec
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPkgPei.dsc
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.h

diff --git a/Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c 
b/Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
new file mode 100644
index 00..5d3b2c14aa
--- /dev/null
+++ b/Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
@@ -0,0 +1,148 @@
+/** @file
+  A DXE_DRIVER providing SMRAM access by producing EFI_SMM_ACCESS2_PROTOCOL.
+
+  X58 TSEG is expected to have been verified and set up by the SmmAccessPei
+  driver.
+
+  Copyright (C) 2013, 2015, Red Hat, Inc.
+  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+#include "SmramInternal.h"
+
+/**
+  Opens the SMRAM area to be accessible by a boot-service driver.
+
+  This function "opens" SMRAM so that it is visible while not inside of SMM.
+  The function should return EFI_UNSUPPORTED if the hardware does not support
+  hiding of SMRAM. The function should return EFI_DEVICE_ERROR if the SMRAM
+  configuration is locked.
+
+  @param[in] This   The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS   The operation was successful.
+  @retval EFI_UNSUPPORTED   The system does not support opening and closing of
+SMRAM.
+  @retval EFI_DEVICE_ERROR  SMRAM cannot be opened, perhaps because it is
+locked.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SmmAccess2DxeOpen (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  return SmramAccessOpen (>LockState, >OpenState);
+}
+
+/**
+  Inhibits access to the SMRAM.
+
+  This function "closes" SMRAM so that it is not visible while outside of SMM.
+  The function should return EFI_UNSUPPORTED if the hardware does not support
+  hiding of SMRAM.
+
+  @param[in] This   The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS   The operation was successful.
+  @retval EFI_UNSUPPORTED   The system does not support opening and closing of
+SMRAM.
+  @retval EFI_DEVICE_ERROR  SMRAM cannot be closed.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SmmAccess2DxeClose (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  return SmramAccessClose (>LockState, >OpenState);
+}
+
+/**
+  Inhibits access to the SMRAM.
+
+  This function prohibits access to the SMRAM region.  This function is usually
+  implemented such that it is a write-once operation.
+
+  @param[in] This  The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS  The device was successfully locked.
+  @retval EFI_UNSUPPORTED  The system does not support locking of SMRAM.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SmmAccess2DxeLock (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  return SmramAccessLock (>LockState, >OpenState);
+}
+
+/**
+  Queries the memory controller for the possible regions that will support
+  SMRAM.
+
+  @param[in] This   The 

[edk2-devel] [edk2-platforms PATCH v4 7/7] SimicsOpenBoardPkg/BoardX58Ich10: Add board modules for QSP Build tip

2019-08-30 Thread David Wei
Add BoardX58ICH10 modules for QSP Build tip

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 .../Library/BoardInitLib/PeiBoardInitPostMemLib.c  |  44 +++
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.c   | 110 
 .../Library/BoardInitLib/PeiX58Ich10Detect.c   |  26 ++
 .../BoardInitLib/PeiX58Ich10InitPostMemLib.c   |  34 +++
 .../BoardInitLib/PeiX58Ich10InitPreMemLib.c| 111 
 .../BoardX58Ich10/DecomprScratchEnd.fdf.inc|  67 +
 .../BoardInitLib/PeiBoardInitPostMemLib.inf|  36 +++
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.inf |  39 +++
 .../Library/BoardInitLib/PeiX58Ich10InitLib.h  |  16 ++
 .../BoardX58Ich10/OpenBoardPkg.dsc | 233 
 .../BoardX58Ich10/OpenBoardPkg.fdf | 304 +
 .../BoardX58Ich10/OpenBoardPkg.fdf.inc |  54 
 .../BoardX58Ich10/OpenBoardPkgBuildOption.dsc  |  78 ++
 .../BoardX58Ich10/OpenBoardPkgConfig.dsc   |  56 
 .../BoardX58Ich10/OpenBoardPkgPcd.dsc  | 281 +++
 .../BoardX58Ich10/VarStore.fdf.inc |  53 
 .../BoardX58Ich10/build_config.cfg |  31 +++
 17 files changed, 1573 insertions(+)
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10Detect.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10InitPostMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10InitPreMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/DecomprScratchEnd.fdf.inc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.inf
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.inf
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10InitLib.h
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkg.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkg.fdf
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkg.fdf.inc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgBuildOption.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgConfig.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/VarStore.fdf.inc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/build_config.cfg

diff --git 
a/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
new file mode 100644
index 00..5ece8c6e34
--- /dev/null
+++ 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
@@ -0,0 +1,44 @@
+/** @file
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitBeforeSiliconInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitAfterSiliconInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+BoardInitBeforeSiliconInit (
+  VOID
+  )
+{
+  X58Ich10BoardInitBeforeSiliconInit ();
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+BoardInitAfterSiliconInit (
+  VOID
+  )
+{
+  X58Ich10BoardInitAfterSiliconInit ();
+  return EFI_SUCCESS;
+}
diff --git 
a/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
new file mode 100644
index 00..d16e649d34
--- /dev/null
+++ 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
@@ -0,0 +1,110 @@
+/** @file
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardDetect(
+  VOID
+  );
+
+EFI_BOOT_MODE
+EFIAPI
+X58Ich10BoardBootModeDetect (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardDebugInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitBeforeMemoryInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitAfterMemoryInit (
+  

[edk2-devel] [edk2-platforms PATCH v4 4/7] SimicsOpenBoardPkg: Add DXE driver for Legacy Sio

2019-08-30 Thread David Wei
Add DXE driver for Legacy Sio support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 .../LegacySioDxe/ComponentName.c   | 173 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.c  | 272 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c| 600 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.c   | 249 +
 .../LegacySioDxe/ComponentName.h   |  87 +++
 .../LegacySioDxe/LegacySioDxe.inf  |  54 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/Register.h |  15 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.h  | 195 +++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h| 134 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.h   | 143 +
 10 files changed, 1922 insertions(+)
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.h
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/LegacySioDxe.inf
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/Register.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.h

diff --git a/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c 
b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
new file mode 100644
index 00..4ba02f92c0
--- /dev/null
+++ b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
@@ -0,0 +1,173 @@
+/** @file
+  Install Base and Size Info Ppi for Firmware Volume Recovery.
+
+  Copyright (c) 2013 - 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "SioDriver.h"
+
+///
+/// Component Name Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  mSioComponentName = 
{
+  SioComponentNameGetDriverName,
+  SioComponentNameGetControllerName,
+  "eng"
+};
+
+///
+/// Component Name 2 Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL mSioComponentName2 
= {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)SioComponentNameGetDriverName,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)SioComponentNameGetControllerName,
+  "en"
+};
+
+///
+/// Table of driver names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE mSioDriverNameTable[] = 
{
+  {
+"eng;en",
+L"Super I/O Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+///
+/// Table of Controller names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mSioControllerNameTable[] = {
+  {
+"eng;en",
+L"Super I/O Controller"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user-readable name of the EFI Driver.
+
+  @param  This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
+  @param  Language   A pointer to a three-character ISO 639-2 language 
identifier.
+ This is the language of the driver name that that the 
caller
+ is requesting, and it must match one of the languages 
specified
+ in SupportedLanguages.  The number of languages supported 
by a
+ driver is up to the driver writer.
+  @param  DriverName A pointer to the Unicode string to return.  This Unicode 
string
+ is the name of the driver specified by This in the 
language
+ specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by 
This
+and the language specified by Language was 
returned
+in DriverName.
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support 
the
+language specified by Language.
+
+**/
+EFI_STATUS
+EFIAPI
+SioComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  )
+{
+  return LookupUnicodeString2 (
+   Language,
+   This->SupportedLanguages,
+   mSioDriverNameTable,
+   DriverName,
+   (BOOLEAN)(This == )
+   );
+}
+
+/**
+  Retrieves a Unicode string that is the user readable name of the controller
+  that is being managed by an EFI Driver.
+
+  @param  This A 

[edk2-devel] [edk2-platforms PATCH v4 0/7] Add Initial QSP MinPlatform Pkg for SIMICS

2019-08-30 Thread David Wei
Create the SimicsOpenBoardPkg and its silicon Pkg to provide the support
for SIMICS quick start platform. it uses X58/ICH10 and emulated by SIMICS
model.

Different from V3:
  Change package name to SimicsIch10BinPkg
  Merge V3 patch changes 8,9,10,11 to proper Package patches
David Wei (7):
  SimicsX58SktPkg:  Add CPU Pkg for SimicsX58
  SimicsIch10Pkg:  Add ICH Pkg for SimicsICH10
  SimicsOpenBoardPkg:  Add SimicsOpenBoardPkg and its modules
  SimicsOpenBoardPkg: Add DXE driver for Legacy Sio
  SimicsOpenBoardPkg:  Add modules and dec file under SimicsOpenBoardPkg
  Platform/Intel:  Add build option for SIMICS QSP Platform
  SimicsOpenBoardPkg/BoardX58Ich10: Add board modules for QSP Build tip

 .../MinPlatformAcpiTables/AcpiPlatform.c   | 1579 
 .../AcpiTables/MinPlatformAcpiTables/Facs/Facs.c   |   84 ++
 .../AcpiTables/MinPlatformAcpiTables/Fadt/Fadt.c   |  359 +
 .../AcpiTables/MinPlatformAcpiTables/Hpet/Hpet.c   |   78 +
 .../AcpiTables/MinPlatformAcpiTables/Wsmt/Wsmt.c   |   46 +
 .../Library/BoardInitLib/PeiBoardInitPostMemLib.c  |   44 +
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.c   |  110 ++
 .../Library/BoardInitLib/PeiX58Ich10Detect.c   |   26 +
 .../BoardInitLib/PeiX58Ich10InitPostMemLib.c   |   34 +
 .../BoardInitLib/PeiX58Ich10InitPreMemLib.c|  111 ++
 .../LegacySioDxe/ComponentName.c   |  173 +++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.c  |  272 
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c|  600 
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.c   |  249 +++
 .../SimicsOpenBoardPkg/Library/DxeLogoLib/Logo.c   |  647 
 .../Library/LoadLinuxLib/Linux.c   |  662 
 .../Library/LoadLinuxLib/LinuxGdt.c|  175 +++
 .../Library/NvVarsFileLib/FsAccess.c   |  507 +++
 .../Library/NvVarsFileLib/NvVarsFileLib.c  |   77 +
 .../Library/PciHostBridgeLib/PciHostBridgeLib.c|  419 ++
 .../SimicsOpenBoardPkg/Library/PeiReportFvLib/Fv.c |  100 ++
 .../Library/PeiReportFvLib/PeiReportFvLib.c|  119 ++
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1553 +++
 .../Library/PlatformBootManagerLib/PlatformData.c  |   35 +
 .../SerializeVariablesLib/SerializeVariablesLib.c  |  869 +++
 .../SiliconPolicyInitLib/SiliconPolicyInitLib.c|  108 ++
 .../SiliconPolicyUpdateLib.c   |   70 +
 .../Intel/SimicsOpenBoardPkg/SecCore/SecMain.c |  956 
 .../Intel/SimicsOpenBoardPkg/SimicsDxe/Platform.c  |  865 +++
 .../SimicsOpenBoardPkg/SimicsDxe/PlatformConfig.c  |  124 ++
 Platform/Intel/SimicsOpenBoardPkg/SimicsPei/Cmos.c |   57 +
 .../SimicsOpenBoardPkg/SimicsPei/FeatureControl.c  |  115 ++
 .../Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c |  568 +++
 .../Intel/SimicsOpenBoardPkg/SimicsPei/Platform.c  |  630 
 .../SimicsVideoDxe/ComponentName.c |  205 +++
 .../SimicsOpenBoardPkg/SimicsVideoDxe/Driver.c | 1011 +
 .../SimicsVideoDxe/DriverSupportedEfiVersion.c |   15 +
 .../Intel/SimicsOpenBoardPkg/SimicsVideoDxe/Gop.c  |  416 ++
 .../SimicsOpenBoardPkg/SimicsVideoDxe/Initialize.c |  341 +
 .../SimicsOpenBoardPkg/SimicsVideoDxe/VbeShim.c|  302 
 .../SmbiosPlatformDxe/SmbiosPlatformDxe.c  |  148 ++
 .../Library/ResetSystemLib/ResetSystemLib.c|  137 ++
 .../Library/SmmSpiFlashCommonLib/SpiFlashCommon.c  |  194 +++
 .../SmmSpiFlashCommonLib/SpiFlashCommonSmmLib.c|   54 +
 .../LibraryPrivate/BasePchSpiCommonLib/SpiCommon.c |  935 
 .../SmmControl/RuntimeDxe/SmmControl2Dxe.c |  410 +
 Silicon/Intel/SimicsIch10Pkg/Spi/Smm/PchSpi.c  |  175 +++
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c |  148 ++
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.c  |  346 +
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.c |  200 +++
 Maintainers.txt|   12 +
 .../SimicsOpenBoardPkg/AcpiTables/AcpiTables.inf   |   31 +
 .../Intel/SimicsOpenBoardPkg/AcpiTables/Dsdt.asl   |  821 ++
 .../MinPlatformAcpiTables/AcpiPlatform.h   |   45 +
 .../MinPlatformAcpiTables/AcpiPlatform.inf |  105 ++
 .../Intel/SimicsOpenBoardPkg/AcpiTables/Platform.h |   75 +
 .../BoardX58Ich10/DecomprScratchEnd.fdf.inc|   67 +
 .../BoardInitLib/PeiBoardInitPostMemLib.inf|   36 +
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.inf |   39 +
 .../Library/BoardInitLib/PeiX58Ich10InitLib.h  |   16 +
 .../BoardX58Ich10/OpenBoardPkg.dsc |  233 +++
 .../BoardX58Ich10/OpenBoardPkg.fdf |  304 
 .../BoardX58Ich10/OpenBoardPkg.fdf.inc |   54 +
 .../BoardX58Ich10/OpenBoardPkgBuildOption.dsc  |   78 +
 .../BoardX58Ich10/OpenBoardPkgConfig.dsc   |   56 +
 .../BoardX58Ich10/OpenBoardPkgPcd.dsc  |  281 
 .../BoardX58Ich10/VarStore.fdf.inc |   53 +

Re: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-30 Thread Laszlo Ersek
On 08/30/19 16:48, Igor Mammedov wrote:

> (01) On boot firmware maps and initializes SMI handler at default SMBASE 
> (3)
>  (using dedicated SMRAM at 3 would allow us to avoid save/restore
>   steps and make SMM handler pointer not vulnerable to DMA attacks)
> 
> (02) QEMU hotplugs a new CPU in reset-ed state and sends SCI
> 
> (03) on receiving SCI, host CPU calls GPE cpu hotplug handler
>   which writes to IO port 0xB2 (broadcast SMI)
> 
> (04) firmware waits for all existing CPUs rendezvous in SMM mode,
>  new CPU(s) have SMI pending but does nothing yet
> 
> (05) host CPU wakes up one new CPU (INIT-INIT-SIPI)
>  SIPI vector points to RO flash HLT loop.
>  (how host CPU will know which new CPUs to relocate?
>   possibly reuse QEMU CPU hotplug MMIO interface???)
> 
> (06) new CPU does relocation.
>  (in case of attacker sends SIPI to several new CPUs,
>   open question how to detect collision of several CPUs at the same 
> default SMBASE)
> 
> (07) once new CPU relocated host CPU completes initialization, returns
>  from IO port write and executes the rest of GPE handler, telling OS
>  to online new CPU.

In step (03), it is the OS that handles the SCI; it transfers control to
ACPI. The AML can write to IO port 0xB2 only because the OS allows it.

If the OS decides to omit that step, and sends an INIT-SIPI-SIPI
directly to the new CPU, can it steal the CPU?

Thanks!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46629): https://edk2.groups.io/g/devel/message/46629
Mute This Topic: https://groups.io/mt/32979681/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms] ClevoOpenBoardPkg: Update board gpios

2019-08-30 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Agyeman, Prince
Sent: Thursday, August 29, 2019 6:12 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Wei, David Y ; 
Kubacki, Michael A ; Desimone, Nathaniel L 
; Chiu, Chasel 
Subject: [edk2-devel] [edk2-platforms] ClevoOpenBoardPkg: Update board gpios

Updated board GPIOS

Cc: Liming Gao 
Cc: David Y Wei 
Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Chasel Chiu 

Signed-off-by: Agyeman 
---
 .../Library/BoardInitLib/N1xxWUGpioTable.c| 329 +-
 1 file changed, 165 insertions(+), 164 deletions(-)

diff --git 
a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxWUGpioTable.c
 
b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxWUGpioTable.c
index d055fda8c3..c99b83753f 100644
--- 
a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxWUGpioTable.c
+++ 
b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxWUGpioTable.c
@@ -20,170 +20,171 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 GPIO_INIT_CONFIG mGpioTableN1xxWU[] =
 {
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A0, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermNone}},//H_RCIN_N
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A1, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//LPC_AD0_ESPI_IO0
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A2, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//LPC_AD1_ESPI_IO1
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A3, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//LPC_AD2_ESPI_IO2
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A4, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//LPC_AD3_ESPI_IO3
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A5,  {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermNone}},//LPC_FRAME_ESPI_CS_N
-//skip for eSPI function  {GPIO_SKL_LP_GPP_A6,  {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermNone}},//INT_SERIRQ
-  {GPIO_SKL_LP_GPP_A7,  {GpioPadModeGpio,GpioHostOwnGpio, GpioDirOut,   
GpioOutHigh,GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//PM_SLP_S0ix_R_N
-// skip for PM_CLKRUN_N {GPIO_SKL_LP_GPP_A8,  {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermNone}},//PM_CLKRUN_N
-//skip for eSPI function{GPIO_SKL_LP_GPP_A9,  {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//LPC_CLK_ESPI_CLK
-// skip for PCH_CLK_PCI_TPM {GPIO_SKL_LP_GPP_A10, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//PCH_CLK_PCI_TPM
-  {GPIO_SKL_LP_GPP_A11, {GpioPadModeGpio,GpioHostOwnGpio, GpioDirIn,
GpioOutDefault, GpioIntLevel | GpioIntApic, GpioHostDeepReset,  
GpioTermNone}},//EC_HID_INTR
-  {GPIO_SKL_LP_GPP_A12, {GpioPadModeGpio,GpioHostOwnGpio, GpioDirOut,   
GpioOutLow,GpioIntDis, GpioResumeReset,  
GpioTermNone}},//M.2_WWAN_GNSS_UART_RST_N
-//skip for SUS_PWR_ACK_R  {GPIO_SKL_LP_GPP_A13, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermNone}},//SUS_PWR_ACK_R
-//skip for eSPI function{GPIO_SKL_LP_GPP_A14, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermNone}},//PM_SUS_STAT_ESPI_RST_N
-//skip for SUSACK_R_N  {GPIO_SKL_LP_GPP_A15, {GpioPadModeNative1, 
GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,  
GpioTermWpd20K}},//SUSACK_R_N
-  {GPIO_SKL_LP_GPP_A16, {GpioPadModeNative1, GpioHostOwnGpio, GpioDirIn,
GpioOutDefault, GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//SD_1P8_SEL
-  {GPIO_SKL_LP_GPP_A17, {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  
GpioOutDefault, GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//SD_PWR_EN_N
-  {GPIO_SKL_LP_GPP_A18, {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  
GpioOutDefault, GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//ISH_GP_0_SENSOR
-  {GPIO_SKL_LP_GPP_A19, {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  
GpioOutDefault, GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//ISH_GP_1_SENSOR
-  {GPIO_SKL_LP_GPP_A20, {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  
GpioOutDefault, GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//ISH_GP_2_SENSOR
-  {GPIO_SKL_LP_GPP_A21, {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  
GpioOutDefault, GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//GNSS_CHUB_IRQ
-  {GPIO_SKL_LP_GPP_A22, {GpioPadModeGpio,

Re: [edk2-devel] [edk2-platforms] ClevoOpenBoardPkg: Update board gpios

2019-08-30 Thread Kubacki, Michael A
Reviewed-by: Michael Kubacki 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Agyeman, Prince
> Sent: Thursday, August 29, 2019 6:12 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Wei, David Y
> ; Kubacki, Michael A
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [edk2-devel] [edk2-platforms] ClevoOpenBoardPkg: Update board
> gpios
> 
> Updated board GPIOS
> 
> Cc: Liming Gao 
> Cc: David Y Wei 
> Cc: Michael Kubacki 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> 
> Signed-off-by: Agyeman 
> ---
>  .../Library/BoardInitLib/N1xxWUGpioTable.c| 329 +-
>  1 file changed, 165 insertions(+), 164 deletions(-)
> 
> diff --git
> a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> index d055fda8c3..c99b83753f 100644
> ---
> a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> +++
> b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> @@ -20,170 +20,171 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  GPIO_INIT_CONFIG mGpioTableN1xxWU[] =
>  {
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A0, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//H_RCIN_N
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A1, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD0_ESPI_IO0
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A2, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD1_ESPI_IO1
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A3, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD2_ESPI_IO2
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A4, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD3_ESPI_IO3
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A5,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//LPC_FRAME_ESPI_CS_N
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A6,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//INT_SERIRQ
> -  {GPIO_SKL_LP_GPP_A7,  {GpioPadModeGpio,GpioHostOwnGpio,
> GpioDirOut,   GpioOutHigh,GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//PM_SLP_S0ix_R_N
> -// skip for PM_CLKRUN_N {GPIO_SKL_LP_GPP_A8,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//PM_CLKRUN_N
> -//skip for eSPI function{GPIO_SKL_LP_GPP_A9,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_CLK_ESPI_CLK
> -// skip for PCH_CLK_PCI_TPM {GPIO_SKL_LP_GPP_A10,
> {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  GpioOutDefault,
> GpioIntDis, GpioHostDeepReset,  GpioTermWpd20K}},//PCH_CLK_PCI_TPM
> -  {GPIO_SKL_LP_GPP_A11, {GpioPadModeGpio,GpioHostOwnGpio,
> GpioDirIn,GpioOutDefault, GpioIntLevel | GpioIntApic,
> GpioHostDeepReset,  GpioTermNone}},//EC_HID_INTR
> -  {GPIO_SKL_LP_GPP_A12, {GpioPadModeGpio,GpioHostOwnGpio,
> GpioDirOut,   GpioOutLow,GpioIntDis, GpioResumeReset,
> GpioTermNone}},//M.2_WWAN_GNSS_UART_RST_N
> -//skip for SUS_PWR_ACK_R  {GPIO_SKL_LP_GPP_A13,
> {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  GpioOutDefault,
> GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//SUS_PWR_ACK_R
> -//skip for eSPI function{GPIO_SKL_LP_GPP_A14, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//PM_SUS_STAT_ESPI_RST_N
> -//skip for SUSACK_R_N  {GPIO_SKL_LP_GPP_A15, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//SUSACK_R_N
> -  {GPIO_SKL_LP_GPP_A16, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirIn,GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//SD_1P8_SEL
> -  {GPIO_SKL_LP_GPP_A17, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//SD_PWR_EN_N
> -  {GPIO_SKL_LP_GPP_A18, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//ISH_GP_0_SENSOR
> -  {GPIO_SKL_LP_GPP_A19, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//ISH_GP_1_SENSOR
> -  {GPIO_SKL_LP_GPP_A20, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//ISH_GP_2_SENSOR
> -  {GPIO_SKL_LP_GPP_A21, 

Re: [edk2-devel] [edk2-platforms: PATCH v2 1/1] Platform/Rpi3: Add compatible property to the "usb" Device Tree node

2019-08-30 Thread Leif Lindholm
On Thu, Aug 29, 2019 at 04:26:58PM +0100, Pete Batard wrote:
> Hi Leif,
> 
> On 2019.08.29 14:54, Leif Lindholm wrote:
> > On Fri, Aug 23, 2019 at 01:20:50PM +0100, Pete Batard wrote:
> > > Some Linux kernels (e.g. Debian) require "bcm,bcm2835-usb" to be present 
> > > in
> > 
> > Is the typo here or in the code? ('bcm,' vs. 'brcm,')
> 
> Sorry, should have been 'brcm,bcm2835-usb' above.
> 
> As mentioned in the cover letter, we're basically adding to the compatible
> string list so that:
>   compatible = "brcm,bcm2708-usb";
> becomes:
>   compatible = "brcm,bcm2708-usb", "brcm,bcm2835-usb";
> 
> So the part before the comma should always be "brcm", and it's only the part
> after that should be "bcm" (which, alas, makes it easy to introduce typos).
> 
> In other words, the typo is in the commit message only.
> 
> I did validate the changes proposed by this patch on real hardware, so I can
> vouch for the code being correct, insofar as the compatible strings there
> are concerned.

Thanks. I was 99% sure that was the case, but I prefer having these
things explicitly clarified before I commit.

> > If here, I can fix up on committing.
> 
> If you can fix the typo in the commit message, that would be great.

Reviewed-by: Leif Lindholm 
Pushed as 5f003136c2bf.

> Regards,
> 
> /Pete
> 
> > 
> > /
> >  Leif
> > 
> > > the list of compatible properties for the "usb" node, else they are unable
> > > to handle some USB devices.
> > > 
> > > This patch ensures that the compatible property is added if not present.
> > > 
> > > Signed-off-by: Pete Batard 
> > > ---
> > >   Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 75 
> > > 
> > >   1 file changed, 75 insertions(+)
> > > 
> > > diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c 
> > > b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> > > index 45ffe2e394a2..eb8048930c30 100644
> > > --- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> > > +++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> > > @@ -135,6 +135,76 @@ UpdateMacAddress (
> > > return EFI_SUCCESS;
> > >   }
> > > +//
> > > +// Add "bcm2835-usb" to the USB compatible property list, if not present.
> > > +// Required because some Linux kernels can't handle USB devices 
> > > otherwise.
> > > +//
> > > +STATIC
> > > +EFI_STATUS
> > > +AddUsbCompatibleProperty (
> > > +  VOID
> > > +  )
> > > +{
> > > +  CONST CHAR8   Prop[]= "brcm,bcm2708-usb";
> > > +  CONST CHAR8   NewProp[] = "brcm,bcm2835-usb";
> > > +  CONST CHAR8   *List;
> > > +  CHAR8 *NewList;
> > > +  INT32 ListSize;
> > > +  INTN  Node;
> > > +  INTN  Retval;
> > > +
> > > +  // Locate the node that the 'usb' alias refers to
> > > +  Node = fdt_path_offset (mFdtImage, "usb");
> > > +  if (Node < 0) {
> > > +DEBUG ((DEBUG_ERROR, "%a: failed to locate 'usb' alias\n", 
> > > __FUNCTION__));
> > > +return EFI_NOT_FOUND;
> > > +  }
> > > +
> > > +  // Get the property list. This is a list of NUL terminated strings.
> > > +  List = fdt_getprop (mFdtImage, Node, "compatible", );
> > > +  if (List == NULL) {
> > > +DEBUG ((DEBUG_ERROR, "%a: failed to locate properties\n", 
> > > __FUNCTION__));
> > > +return EFI_NOT_FOUND;
> > > +  }
> > > +
> > > +  // Check if the compatible value we plan to add is already present
> > > +  if (fdt_stringlist_contains (List, ListSize, NewProp)) {
> > > +DEBUG ((DEBUG_INFO, "%a: property '%a' is already set.\n",
> > > +  __FUNCTION__, NewProp));
> > > +return EFI_SUCCESS;
> > > +  }
> > > +
> > > +  // Make sure the compatible device is what we expect
> > > +  if (!fdt_stringlist_contains (List, ListSize, Prop)) {
> > > +DEBUG ((DEBUG_ERROR, "%a: property '%a' is missing!\n",
> > > +  __FUNCTION__, Prop));
> > > +return EFI_NOT_FOUND;
> > > +  }
> > > +
> > > +  // Add the new NUL terminated entry to our list
> > > +  DEBUG ((DEBUG_INFO, "%a: adding '%a' to the properties\n",
> > > +__FUNCTION__, NewProp));
> > > +
> > > +  NewList = AllocatePool (ListSize + sizeof (NewProp));
> > > +  if (NewList == NULL) {
> > > +DEBUG ((DEBUG_ERROR, "%a: failed to allocate memory\n", 
> > > __FUNCTION__));
> > > +return EFI_OUT_OF_RESOURCES;;
> > > +  }
> > > +  CopyMem (NewList, List, ListSize);
> > > +  CopyMem ([ListSize], NewProp, sizeof (NewProp));
> > > +
> > > +  Retval = fdt_setprop (mFdtImage, Node, "compatible", NewList,
> > > + ListSize + sizeof (NewProp));
> > > +  FreePool (NewList);
> > > +  if (Retval != 0) {
> > > +DEBUG ((DEBUG_ERROR, "%a: failed to update properties (%d)\n",
> > > +  __FUNCTION__, Retval));
> > > +return EFI_NOT_FOUND;
> > > +  }
> > > +
> > > +  return EFI_SUCCESS;
> > > +}
> > > +
> > >   STATIC
> > >   EFI_STATUS
> > >   CleanMemoryNodes (
> > > @@ -486,6 +556,11 @@ FdtDxeInitialize (
> > >   Print (L"Failed to update MAC address: %r\n", Status);
> > > }
> > > +  Status = AddUsbCompatibleProperty ();
> > > +  if 

Re: [edk2-devel] [edk2-platforms: PATCH 1/1] DisplayLinkPkg: DisplayLinkGop: Added GOP driver for USB docking stations based on DisplayLink chips

2019-08-30 Thread Leif Lindholm
Hi Andy,

This looks fine to me - all my feedback has been addressed.
Reviewed-by: Leif Lindholm 

Ray - did you have any comments on this, or can I go ahead and commit?

Best Regards,

Leif

On Mon, Aug 19, 2019 at 02:32:00PM +0100, Andy Hayes wrote:
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Signed-off-by: Andy Hayes 
> ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c |  
> 137 +++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/ComponentName.c|  
> 235 +
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/DisplayLinkGopDxe.inf  |   
> 65 ++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c |  
> 598 +++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.h |  
> 129 +++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c  |  
> 578 +++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c   |  
> 145 +++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.h   |  
> 109 ++
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c   | 
> 1082 
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.h   |  
> 278 +
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c  |  
> 180 
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/VideoModes.c   |  
> 254 +
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc|   
> 61 ++
>  Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md |   
> 77 ++
>  Maintainers.txt  |   
>  5 +
>  15 files changed, 3933 insertions(+)
> 
> diff --git 
> a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c 
> b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c
> new file mode 100644
> index ..4bfadd770b81
> --- /dev/null
> +++ b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c
> @@ -0,0 +1,137 @@
> +/** @file CapabilityDescriptor.c
> + * @brief Definitions for reading USB capability descriptor DisplayLink dock
> + *
> + * Copyright (c) 2018-2019, DisplayLink (UK) Ltd. All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-2-Clause-Patent
> + *
> +**/
> +
> +#include "UsbDisplayLink.h"
> +#include "UsbDescriptors.h"
> +
> +/**
> + * Check that the Capability Descriptor is valid and hasn't been tampered 
> with.
> + * @param Data Binary data of the Capability Descriptor received from the 
> DisplayLink device
> + * @param Length
> + * @param out
> + * @return
> + */
> +STATIC EFI_STATUS
> +ValidateHeader (
> +CONST IN VOID* Data,
> +IN UINTN Length,
> +OUT CONST VendorDescriptorGeneric** Out
> +)
> +{
> +  if (Length < sizeof (VendorDescriptorGeneric)) {
> +DEBUG ((DEBUG_ERROR, "Data too short (%d bytes) for capability 
> descriptor header section\n", Length));
> +return EFI_INVALID_PARAMETER;
> +  }
> +  CONST VendorDescriptorGeneric* Desc = (VendorDescriptorGeneric*)Data;
> +  if (Desc->Length > Length) {
> +DEBUG ((DEBUG_ERROR, "Capability descriptor: Descriptor (%d bytes) 
> exceeds buffer (%d bytes)\n",
> +  Length, Desc->Length));
> +return EFI_BUFFER_TOO_SMALL;
> +  }
> +  if (Desc->Type != DESCRIPTOR_TYPE_DIRECTFB_CAPABILITY) {
> +DEBUG ((DEBUG_ERROR, "Capability descriptor: invalid type (0x%08x)\n", 
> Desc->Type));
> +return EFI_UNSUPPORTED;
> +  }
> +  if (Desc->CapabilityVersion != 1) {
> +DEBUG ((DEBUG_ERROR, "Capability descriptor: invalid version (%d)\n", 
> Desc->CapabilityVersion));
> +return EFI_INCOMPATIBLE_VERSION;
> +  }
> +  // Capability length must fit within remaining space
> +  if (Desc->CapabilityLength > (Desc->Length - (sizeof (Desc->Length) + 
> sizeof (Desc->Type {
> +DEBUG ((DEBUG_ERROR, "Capability descriptor: invalid CapabilityLength 
> (%d)\n", Desc->CapabilityLength));
> +return EFI_INVALID_PARAMETER;
> +  }
> +  *Out = Desc;
> +  return EFI_SUCCESS;
> +}
> +
> +
> +/**
> + * Check that the connected DisplayLink device supports the functionality 
> that this driver requires, e.g. video formats
> + * @param Data Binary data of the Capability Descriptor received from the 
> DisplayLink device
> + * @param Length
> + * @param Output
> + * @return
> + */
> +EFI_STATUS
> +UsbDisplayLinkParseCapabilitiesDescriptor (
> +CONST IN VOID* Data,
> +IN UINTN Length,
> +OUT VendorDescriptor* Output
> +)
> +{
> +  CONST VendorDescriptorGeneric* Desc;
> +  EFI_STATUS Status;
> +
> +  Desc = NULL;
> +  Status = ValidateHeader (Data, Length, );
> +
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  // Default capabilities
> +  Output->Capabilities1 = 0;
> +
> +  CONST UINTN CapsHeaderLength = sizeof (Desc->CapabilityVersion) + sizeof 
> (Desc->CapabilityLength);
> +  ASSERT (CapsHeaderLength < MAX_UINT8);
> +
> + 

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-30 Thread Igor Mammedov
On Thu, 29 Aug 2019 18:25:17 +0200
Laszlo Ersek  wrote:

> On 08/28/19 14:01, Igor Mammedov wrote:
> > On Tue, 27 Aug 2019 22:11:15 +0200
> > Laszlo Ersek  wrote:
> >   
> >> On 08/27/19 18:23, Igor Mammedov wrote:
> >>> On Mon, 26 Aug 2019 17:30:43 +0200
> >>> Laszlo Ersek  wrote:
> >>>
>  On 08/23/19 17:25, Kinney, Michael D wrote:
> > Hi Jiewen,
> >
> > If a hot add CPU needs to run any code before the
> > first SMI, I would recommend is only executes code
> > from a write protected FLASH range without a stack
> > and then wait for the first SMI.
> 
>  "without a stack" looks very risky to me. Even if we manage to implement
>  the guest code initially, we'll be trapped without a stack, should we
>  ever need to add more complex stuff there.
> >>>
> >>> Do we need anything complex in relocation handler, though?
> >>> From what I'd imagine, minimum handler should
> >>>   1: get address of TSEG, possibly read it from chipset
> >>
> >> The TSEG base calculation is not trivial in this environment. The 32-bit
> >> RAM size needs to be read from the CMOS (IO port accesses). Then the
> >> extended TSEG size (if any) needs to be detected from PCI config space
> >> (IO port accesses). Both CMOS and PCI config space requires IO port
> >> writes too (not just reads). Even if there are enough registers for the
> >> calculations, can we rely on these unprotected IO ports?
> >>
> >> Also, can we switch to 32-bit mode without a stack? I assume it would be
> >> necessary to switch to 32-bit mode for 32-bit arithmetic.
> > from SDM vol 3:
> > "
> > 34.5.1 Initial SMM Execution Environment
> > After saving the current context of the processor, the processor 
> > initializes its core registers to the values shown in Table 34-4. Upon 
> > entering SMM, the PE and PG flags in control register CR0 are cleared, 
> > which places the processor in an environment similar to real-address mode. 
> > The differences between the SMM execution environment and the real-address 
> > mode execution environment are as follows:
> > • The addressable address space ranges from 0 to H (4 GBytes).
> > • The normal 64-KByte segment limit for real-address mode is increased to 4 
> > GBytes.
> > • The default operand and address sizes are set to 16 bits, which restricts 
> > the addressable SMRAM address space to the 1-MByte real-address mode limit 
> > for native real-address-mode code. However, operand-size and address-size 
> > override prefixes can be used to access the address space beyond
> >  
> > the 1-MByte.
> > "
> 
> That helps. Thanks for the quote!
> 
> >> Getting the initial APIC ID needs some CPUID instructions IIUC, which
> >> clobber EAX through EDX, if I understand correctly. Given the register
> >> pressure, CPUID might have to be one of the first instructions to call.
> > 
> > we could map at 3 not 64K required for save area but 128K and use
> > 2nd half as secure RAM for stack and intermediate data.
> > 
> > Firmware could put there pre-calculated pointer to TSEG after it's 
> > configured and locked down,
> > this way relocation handler won't have to figure out TSEG address on its 
> > own.
> 
> Sounds like a great idea.
> 
> >>>   2: calculate its new SMBASE offset based on its APIC ID
> >>>   3: save new SMBASE
> >>>
> > For this OVMF use case, is any CPU init required
> > before the first SMI?
> 
>  I expressed a preference for that too: "I wish we could simply wake the
>  new CPU [...] with an SMI".
> 
>  398b3327-0820-95af-a34d-1a4a1d50cf35@redhat.com">http://mid.mail-archive.com/398b3327-0820-95af-a34d-1a4a1d50cf35@redhat.com
> 
> 
> > From Paolo's list of steps are steps (8a) and (8b) 
> > really required?
> >>>
> >>> 07b - implies 08b
> >>
> >> I agree about that implication, yes. *If* we send an INIT/SIPI/SIPI to
> >> the new CPU, then the new CPU needs a HLT loop, I think.
> > It also could execute INIT reset, which leaves initialized SMM untouched
> > but otherwise CPU would be inactive.
> >
> >>
> >>>8b could be trivial hlt loop and we most likely could skip 08a and 
> >>> signaling host CPU steps
> >>>but we need INIT/SIPI/SIPI sequence to wake up AP so it could handle 
> >>> pending SMI
> >>>before handling SIPI (so behavior would follow SDM).
> >>>
> >>>
>  See again my message linked above -- just after the quoted sentence, I
>  wrote, "IOW, if we could excise steps 07b, 08a, 08b".
> 
>  But, I obviously defer to Paolo and Igor on that.
> 
>  (I do believe we have a dilemma here. In QEMU, we probably prefer to
>  emulate physical hardware as faithfully as possible. However, we do not
>  have Cache-As-RAM (nor do we intend to, IIUC). Does that justify other
>  divergences from physical hardware too, such as waking just by virtue of
>  an SMI?)
> >>> So far we should be able to implement it per spec (at least SDM 

Re: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-30 Thread Igor Mammedov
On Thu, 29 Aug 2019 19:01:35 +0200
Laszlo Ersek  wrote:

> On 08/27/19 20:31, Igor Mammedov wrote:
> > On Sat, 24 Aug 2019 01:48:09 +
> > "Yao, Jiewen"  wrote:  
> 
> >> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
> >>  will not enter CPU because SMI is disabled)  
> > I think only CPU that does the write will enter SMM  
> 
> That used to be the case (and it is still the default QEMU behavior, if
> broadcast SMI is not negotiated). However, OVMF does negotiate broadcast
> SMI whenever QEMU offers the feature. Broadcast SMI is important for the
> stability of the edk2 SMM infrastructure on QEMU/KVM, we've found.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1412313
> https://bugzilla.redhat.com/show_bug.cgi?id=1412327
> 
> > and we might not need to pull in all already initialized CPUs into SMM.  
> 
> That, on the other hand, could be a valid idea. But then the CPU should
> use a different method for raising a synchronous SMI for itself (not a
> write to IO port 0xB2). Is a "directed SMI for self" possible?

theoretically depending on argument in 0xb3, it should be possible to
rise directed SMI even if broadcast ones are negotiated.

> > [...]  
> 
> I've tried to read through the procedure with your suggested changes,
> but I'm failing at composing a coherent mental image, in this email
> response format.
> 
> If you have the time, can you write up the suggested list of steps in a
> "flat" format? (I believe you are suggesting to eliminate some steps
> completely.)
if I'd sum it up:

(01) On boot firmware maps and initializes SMI handler at default SMBASE (3)
 (using dedicated SMRAM at 3 would allow us to avoid save/restore
  steps and make SMM handler pointer not vulnerable to DMA attacks)

(02) QEMU hotplugs a new CPU in reset-ed state and sends SCI

(03) on receiving SCI, host CPU calls GPE cpu hotplug handler
  which writes to IO port 0xB2 (broadcast SMI)

(04) firmware waits for all existing CPUs rendezvous in SMM mode,
 new CPU(s) have SMI pending but does nothing yet

(05) host CPU wakes up one new CPU (INIT-INIT-SIPI)
 SIPI vector points to RO flash HLT loop.
 (how host CPU will know which new CPUs to relocate?
  possibly reuse QEMU CPU hotplug MMIO interface???)

(06) new CPU does relocation.
 (in case of attacker sends SIPI to several new CPUs,
  open question how to detect collision of several CPUs at the same default 
SMBASE)

(07) once new CPU relocated host CPU completes initialization, returns
 from IO port write and executes the rest of GPE handler, telling OS
 to online new CPU.


> ... jumping to another point:
> 
> >> 2) Let trusted software (SMM and init code) guarantee SMREBASE one by one 
> >> (include any code runs before SMREBASE)  
> > that would mean pulling all present CPUs into SMM mode so no attack
> > code could be executing before doing hotplug. With a lot of present CPUs
> > it could be quite expensive and unlike physical hardware, guest's CPUs
> > could be preempted arbitrarily long causing long delays.  
> 
> I agree with your analysis, but I slightly disagree about the impact:
> 
> - CPU hotplug is not a frequent administrative action, so the CPU load
> should be temporary (it should be a spike). I don't worry that it would
> trip up OS kernel code. (SMI handling is known to take long on physical
> platforms oo.) In practice, all "normal" SMIs are broadcast already (for
> example when calling the runtime UEFI variable services from the OS kernel).
> 
> - The fact that QEMU/KVM introduces some jitter into the execution of
> multi-core code (including SMM code) has proved useful in the past, for
> catching edk2 regressions.
> 
> Again, this is not a strong disagreement from my side. I'm open to
> better ways for synching CPUs during muti-CPU-hotplug.
> 
> (Digression:
> 
> I expect someone could be curious why (a) I find it acceptable (even
> beneficial) that "some jitter" injected by the QEMU/KVM scheduling
> exposes multi-core regressions in edk2, but at the same time (b) I found
> it really important to add broadcast SMI to QEMU and OVMF. After all,
> both "jitter" and "unicast SMIs" are QEMU/KVM platform specifics, so why
> the different treatment?
> 
> The reason is that the "jitter" does not interfere with normal
> operation, and it has been good for catching *regressions*. IOW, there
> is a working edk2 state, someone posts a patch, works on physical
> hardware, but breaks on QEMU/KVM --> then we can still reject or rework
> or revert the patch. And we're back to a working state again (in the
> best case, with a fixed feature patch).
> 
> With the unicast SMIs however, it was impossible to enable the SMM stack
> reliably in the first place. There was no functional state to return to.
I don't really get the last statement, but the I know nothing about OVMF.
I don't insist on unicast SMI being used, it's just some ideas about what
we could do. It could be done later, broadcast 

Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1

2019-08-30 Thread Laszlo Ersek
Hi Sean,

On 08/30/19 04:21, Sean via Groups.Io wrote:
> would like to see these two efforts merged together.

> Currently if the full set of tests are run we take about 20 minutes.
> This is because compiling MdeModulePkg for debug, release, and host
> based tests take a while.  Most other packages are in the 10 minute
> range.  We do have easy ways to disable or limit certain tests as well
> as expand the matrix to leverage more cloud resources (more parallel
> builds).

> ### Module Inclusion Test - DscCompleteCheck
> ### Code Compilation Test - CompilerPlugin
> ### Host-Based UnitTests - HostUnitTestCompilerPlugin and
> HostUnitTestDscCompleteCheck
> ### GUID Uniqueness Test - GuidCheck
> ### Cross-Package Dependency Test - DependencyCheck
> ### Library Declaration Test - LibraryClassCheck
> ### Invalid Character Test - CharEncodingCheck

These tests sound awesome!

> ## Next Steps
>
> * Receive community feedback on RFC.
> * Determine where this phase makes sense given existing RFCs from
>   other TianoCore contributors.
> * Optimize testing beharior.
>   * Only run a subset of tests on PRs or individual commits.
>   * Run full testing either once per day or once every several
  commits.

I'd like to keep the per-PR tests down to 10 minutes.

On the other hand, it would be great if all of these tests could be
performed daily or weekly.

Are these tests easy to integrate with the infrastructure described by
Mike?

Thanks,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46622): https://edk2.groups.io/g/devel/message/46622
Mute This Topic: https://groups.io/mt/33072637/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1

2019-08-30 Thread Laszlo Ersek
On 08/30/19 10:43, Liming Gao wrote:
> Mike:
>   I add my comments. 
> 
>> -Original Message-
>> From: r...@edk2.groups.io [mailto:r...@edk2.groups.io] On Behalf Of Michael
>> D Kinney
>> Sent: Friday, August 30, 2019 4:23 AM
>> To: devel@edk2.groups.io; r...@edk2.groups.io
>> Subject: [edk2-rfc] [RFC] EDK II Continuous Integration Phase 1
>>
>> Hello,
>>
>> This is a proposal for a first step towards continuous
>> integration for all TianoCore repositories to help
>> improve to quality of commits and automate testing and
>> release processes for all EDK II packages and platforms.
>>
>> This is based on work from a number of EDK II community
>> members that have provide valuable input and evaluations.
>>
>> * Rebecca Cran  Jenkins evaluation
>> * Laszlo Ersek  GitLab evaluation
>> * Philippe Mathieu-Daudé  GitLab evaluation
>> * Sean Brogan  Azure Pipelines and HBFA
>> * Bret Barkelew  Azure Pipelines and HBFA
>> * Jiewen Yao  HBFA
>>
>> The following link is a link to an EDK II WIKI page that
>> contains a summary of the work to date.  Please provide
>> feedback in the EDK II mailing lists.  The WIKI pages will
>> be updated with input from the entire EDK II community.
>>
>>https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Continuous-
>> Integration
>>
>> Proposal
>> 
>> Phase 1 of adding continuous integration is limited to the
>> edk2 repository.  Additional repositories will be added later.
>>
>> The following changes are proposed:
>> * Remove EDK II Maintainers write access to edk2 repository.
>>  Only EDK II Administrators will continue to have write
>>  access, and that should only be used to handle extraordinary
>>  events.
>> * EDK II Maintainers use a GitHub Pull Request instead of push
>>  to commit a patch series to the edk2 repository.  There are
>>  no other changes to the development and review process.  The
>>  patch series is prepared in an EDK II maintainer branch with
>>  all commit message requirements met on each patch in the series.
> 
> Will the maintainer manually provide pull request after the patch passes the 
> review?

Yes. The maintainer will prepare a local branch that is rebased to
master, and has all the mailing list feedback tags (Reviewed-by, etc)
applied. The maintainer also does all the local testing that they
usually do, just before the final "git push origin".

Then, the final "git push origin" action is replaced by:
(1) git push personal-repo topic-branch-pr
(2) manual creation of a GitHub.com Pull Request, for the topic branch
just pushed.

That is, the final "git push origin" action is replaced with the pushing
of a personal (ready-made) topic branch, and a GitHub.com Pull Request
against that branch. The verification and the final merging will be
performed by github.

> Can the script scan the mail list and auto trig pull request once the patch 
> gets 
> Reviewed-by or Acked-by from Package maintainers?

No, it can't. (And, at this stage, it should not.) The coordination
between submitters, maintainers, reviewers, and occasionally, stewards,
for determining when a patch series is ready to go, based on review
discussion, remains the same.

>> * The edk2 repository only accepts Pull Requests from members
>>  of the EDK II Maintainers team.  Pull Requests from anyone else
>>  are rejected.
>> * Run pre-commit checks using Azure Pipelines
> 
> The maintainer manually trig pre-commit check or auto trig pre-commit?

After the maintainer pushes the ready-made branch to their personal
repo, and submits a PR against that, the PR will set off the checks. If
the checks pass, the topic branch is merged.

> By default, pre-commit should be auto trigged based on pull request. 
> 
>> * If all pre-commit checks pass, then the patch series is auto
>>  committed.  The result of this commit must match the contents
>>  and commit history that would have occurred using the previous
>>  push operation.
>> * If any pre-commit checks fail, then notify the submitter.
> 
> Will Pre-commit check fail send the mail to the patch submitter?
> The patch submitter need update the patch and go through review process 
> again. 

My understanding is that, if the testing in GitHub.com fails, the PR
will be rejected and closed. This will generate a notification email for
the maintainer that submitted the PR. The maintainer can then return to
the email thread, and report the CI failure, possibly with a link to the
failed / rejected PR.

Then, indeed, the submitter must rework the series and post a new
version to the list.

It's also possible (and polite) if the maintainer posts the PR link in
the mailing list thread right after submitting the PR. Then the
submitter can monitor the PR too. (Subscribe to it for notifications.)
As I understand it.

Furthermore,

> 
>>  A typical reason for a failure would be a merge conflict with
>>  another pull request that was just processed.
>> * Limit pre-commit checks execution time to 10 minutes.
>> * Provide on-demand builds to EDK 

Re: [edk2-devel] [edk2-platforms] ClevoOpenBoardPkg: Update board gpios

2019-08-30 Thread Chiu, Chasel


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Agyeman, Prince
> Sent: Friday, August 30, 2019 9:12 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Wei, David Y
> ; Kubacki, Michael A ;
> Desimone, Nathaniel L ; Chiu, Chasel
> 
> Subject: [edk2-platforms] ClevoOpenBoardPkg: Update board gpios
> 
> Updated board GPIOS
> 
> Cc: Liming Gao 
> Cc: David Y Wei 
> Cc: Michael Kubacki 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> 
> Signed-off-by: Agyeman 
> ---
>  .../Library/BoardInitLib/N1xxWUGpioTable.c| 329 +-
>  1 file changed, 165 insertions(+), 164 deletions(-)
> 
> diff --git
> a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> index d055fda8c3..c99b83753f 100644
> ---
> a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> +++
> b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/Library/BoardInitLib/N1xxW
> UGpioTable.c
> @@ -20,170 +20,171 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  GPIO_INIT_CONFIG mGpioTableN1xxWU[] =
>  {
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A0, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//H_RCIN_N
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A1, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD0_ESPI_IO0
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A2, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD1_ESPI_IO1
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A3, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD2_ESPI_IO2
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A4, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_AD3_ESPI_IO3
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A5,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//LPC_FRAME_ESPI_CS_N
> -//skip for eSPI function  {GPIO_SKL_LP_GPP_A6,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//INT_SERIRQ
> -  {GPIO_SKL_LP_GPP_A7,  {GpioPadModeGpio,GpioHostOwnGpio,
> GpioDirOut,   GpioOutHigh,GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//PM_SLP_S0ix_R_N
> -// skip for PM_CLKRUN_N {GPIO_SKL_LP_GPP_A8,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//PM_CLKRUN_N
> -//skip for eSPI function{GPIO_SKL_LP_GPP_A9,  {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//LPC_CLK_ESPI_CLK
> -// skip for PCH_CLK_PCI_TPM {GPIO_SKL_LP_GPP_A10,
> {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  GpioOutDefault,
> GpioIntDis, GpioHostDeepReset,  GpioTermWpd20K}},//PCH_CLK_PCI_TPM
> -  {GPIO_SKL_LP_GPP_A11, {GpioPadModeGpio,GpioHostOwnGpio,
> GpioDirIn,GpioOutDefault, GpioIntLevel | GpioIntApic,
> GpioHostDeepReset,  GpioTermNone}},//EC_HID_INTR
> -  {GPIO_SKL_LP_GPP_A12, {GpioPadModeGpio,GpioHostOwnGpio,
> GpioDirOut,   GpioOutLow,GpioIntDis, GpioResumeReset,
> GpioTermNone}},//M.2_WWAN_GNSS_UART_RST_N
> -//skip for SUS_PWR_ACK_R  {GPIO_SKL_LP_GPP_A13,
> {GpioPadModeNative1, GpioHostOwnGpio, GpioDirNone,  GpioOutDefault,
> GpioIntDis, GpioHostDeepReset,  GpioTermNone}},//SUS_PWR_ACK_R
> -//skip for eSPI function{GPIO_SKL_LP_GPP_A14, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermNone}},//PM_SUS_STAT_ESPI_RST_N
> -//skip for SUSACK_R_N  {GPIO_SKL_LP_GPP_A15, {GpioPadModeNative1,
> GpioHostOwnGpio, GpioDirNone,  GpioOutDefault, GpioIntDis,
> GpioHostDeepReset,  GpioTermWpd20K}},//SUSACK_R_N
> -  {GPIO_SKL_LP_GPP_A16, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirIn,GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//SD_1P8_SEL
> -  {GPIO_SKL_LP_GPP_A17, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//SD_PWR_EN_N
> -  {GPIO_SKL_LP_GPP_A18, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//ISH_GP_0_SENSOR
> -  {GPIO_SKL_LP_GPP_A19, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//ISH_GP_1_SENSOR
> -  {GPIO_SKL_LP_GPP_A20, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, GpioIntDis, GpioHostDeepReset,
> GpioTermNone}},//ISH_GP_2_SENSOR
> -  {GPIO_SKL_LP_GPP_A21, {GpioPadModeNative1, GpioHostOwnGpio,
> GpioDirNone,  GpioOutDefault, 

Re: [edk2-devel] [PATCH] CoffeelakeSiliconPkg: Add a needed ZeroMem ()

2019-08-30 Thread Chiu, Chasel


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Kubacki, Michael A
> Sent: Friday, August 30, 2019 7:16 AM
> To: devel@edk2.groups.io; Desimone, Nathaniel L
> 
> Cc: Chiu, Chasel ; Chaganty, Rangasai V
> 
> Subject: RE: [edk2-devel] [PATCH] CoffeelakeSiliconPkg: Add a needed
> ZeroMem ()
> 
> In the future, the subject should include [edk2-platforms] for patches in the
> repo.
> 
> Reviewed-by: Michael Kubacki 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Nate
> > DeSimone
> > Sent: Thursday, August 29, 2019 4:00 PM
> > To: devel@edk2.groups.io
> > Cc: Chiu, Chasel ; Kubacki, Michael A
> > ; Chaganty, Rangasai V
> > 
> > Subject: [edk2-devel] [PATCH] CoffeelakeSiliconPkg: Add a needed
> > ZeroMem ()
> >
> > AddComponentConfigBlocks () should ZeroMem () the Config Block Header
> > before using it.
> >
> > Cc: Chasel Chiu 
> > Cc: Michael Kubacki 
> > Cc: Sai Chaganty 
> > Signed-off-by: Nate DeSimone 
> > ---
> >  .../Library/BaseSiConfigBlockLib/BaseSiConfigBlockLib.c  | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git
> > a/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/Base
> > SiCon
> > figBlockLib.c
> > b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/Base
> > SiCon
> > figBlockLib.c
> > index 16a14b3245..3c02a4563c 100644
> > ---
> > a/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/Base
> > SiCon
> > figBlockLib.c
> > +++
> > b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/Base
> > SiCon
> > figBlockLib.c
> > @@ -75,6 +75,7 @@ AddComponentConfigBlocks (
> >// Loop to identify each config block from ComponentBlocks[] Table
> > and add each of them
> >//
> >for (BlockCount = 0 ; BlockCount < TotalBlockCount; BlockCount++) {
> > +ZeroMem (, sizeof (CONFIG_BLOCK));
> >  CopyMem (&(ConfigBlockBuf.Header.GuidHob.Name),
> > ComponentBlocks[BlockCount].Guid, sizeof (EFI_GUID));
> >  ConfigBlockBuf.Header.GuidHob.Header.HobLength =
> > ComponentBlocks[BlockCount].Size;
> >  ConfigBlockBuf.Header.Revision=
> > ComponentBlocks[BlockCount].Revision;
> > --
> > 2.17.1.windows.2
> >
> >
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46619): https://edk2.groups.io/g/devel/message/46619
Mute This Topic: https://groups.io/mt/33073966/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] gitbook.com integration doesn't seem to work

2019-08-30 Thread Laszlo Ersek
Hi Mike,

I've written three patches for the C Coding Standards document (for
addressing TianoCore#607), and pushed them to my personal repo:

  https://github.com/lersek/edk2-CCodingStandardsSpecification

on branch

  spurious_assign_bz_607

The latest commit is presently commit 66b44ceed69d ("must comment: add
rule for documenting spurious variable assignments", 2019-08-30).


On GitBooks.com, I had created a personal fork of the CCS about two
years ago, and I had set up the integration with my GitHub.com
repository. Back then, the integration worked fine, and when I posted
some CCS patches, I was able to link rendered views of the modified
pages in the cover letter. See for example the following posting:

  [edk2] [edk2-CCodingStandardsSpecification PATCH 0/2]
  improvements related to line wrapping

  https://lists.01.org/pipermail/edk2-devel/2017-August/013165.html

Specifically, the URL

  
https://lersek.gitbooks.io/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/content/v/line_wrapping/

continues to work to this day, with the "line_wrapping" part
corresponding to the branch name from two years ago.


Now, the problem is that I seem unable to get a rendered view of my new
branch, called "spurious_assign_bz_607". If I simply replace
"line_wrapping" with the new branch name in the URL above, I get "Page
Not Found".

In my "Settings" dialog on GitBooks.com:

  
https://legacy.gitbook.com/book/lersek/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/settings

I have verified that GitBooks.com sees the new branch, and that the
GitBooks.com and GitHub.com repositories are "in sync":

  
https://legacy.gitbook.com/book/lersek/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/settings/github

Furthermore, the "update count" at

  
https://legacy.gitbook.com/book/lersek/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/activity

has increased from "4" to "5", which is valud -- but then the activity
log for the specific branches is questionable:

- when I select the master branch, while the activity log references the
  latest commit on master correctly (d096859f15b9), it labels it "12
  hours ago" -- which is bogus, as that patch was commited on
  2019-Apr-18,

- when I select the new branch, called "spurious_assign_bz_607" -- note:
  I *can* select it --, I get "Nothing to show! There is currently no
  updates on this branch".

So basically the integration with github.com seems to have fallen apart.

Has anyone else seen this? How can we fix it?

I don't feel comfortable posting CCS patches without verifying a
rendered HTML view on GitBooks.com.

Thanks!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46618): https://edk2.groups.io/g/devel/message/46618
Mute This Topic: https://groups.io/mt/33079068/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] MdePkg/DxeHstiLib: Added checks to improve error handling.

2019-08-30 Thread Laszlo Ersek
On 08/30/19 04:21, Desimone, Nathaniel L wrote:
> It is possible to use git send-email with an exchange server by using
> DavMail as a relay. I would
> recommend that we encourage those whom work at a company which does
> not allow outbound SMTP connections to send their edk2 patches using
> this method.

This sounds hugely important and helpful.

Can people using Outlook please test this setup and report back?

Many thanks, Nate!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46617): https://edk2.groups.io/g/devel/message/46617
Mute This Topic: https://groups.io/mt/33041050/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] MdePkg/DxeHstiLib: Added checks to improve error handling.

2019-08-30 Thread Laszlo Ersek
On 08/29/19 19:02, Ni, Ray wrote:
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Thursday, August 29, 2019 7:24 AM
>> To: Leif Lindholm ; Ni, Ray 
>> Cc: Gao, Liming ; Cetola, Stephano 
>> ; Kinney, Michael D
>> ; jayanth.raghu...@dell.com; 'Andrew Fish 
>> (af...@apple.com)' ;
>> wei.g@dell.com; devel@edk2.groups.io
>> Subject: Re: [edk2-devel] [PATCH] MdePkg/DxeHstiLib: Added checks to improve 
>> error handling.

>> - Doesn't work for patch series, only for single patches.
> Laszlo,
> Do you mean attachment is not allowed for a series of patch?

That's correct; I mean that.

> Why? A mail can carry multiple attachments. That makes the patch series easy 
> to fetch in my opinion from Outlook.

The goal is to enable fine-grained, email based review comments.
Meaning, a reviewer responds to the original email, whereby the original
patch is quoted in full in the response. Then the reviewer inserts
comments near the code locations in the patch that need updates.

This approach works perfectly when the original email was sent with
git-send-email.

The approach works tolerably (as an exception to our workflow) when the
original email was sent manually, with a single patch pasted or
attached. Because, in this case, the review comments can still be made
context-sensitively, and the threading structure will be sane.

The approach does not work at all when a single email carries multiple
patches. Quoting becomes a mess, review comments are a lot more
difficult to associate with the targeted patch within the series, and so on.

If the contribution is a patch series (i.e., not a single patch), and
the submitter is unable to use "git-send-email", then the submitter is
responsible for manually establishing the exact same shallow thread
structure that git-send-email would. Specifically, the submitter first
needs to send a cover letter email, then they need to send each patch
individually, with numbered subjects, in direct response to the cover
letter email. They can paste or attach one patch per email, until the
full series is posted.

The email thread must reflect the git commits so that a specific git
commit has a matching "entry point" into the mailing list discussion --
i.e., a reviewer interested in a given git commit can find the precisely
matching email, and the related *sub*-thread that discusses that
particular commit.

Email is not merely a dumb carrier for patches where it's OK to drop a
single patch-bomb email (let alone a ZIP file) on reviewers. A
well-structured email thread is vital to careful review, and for the
long-term archival of the discussion.

Thanks,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46616): https://edk2.groups.io/g/devel/message/46616
Mute This Topic: https://groups.io/mt/33041050/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2 1/1] MdePkg: UefiLib: Add a function to check if a language is supported

2019-08-30 Thread Tom Zhao
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2100

Add a function that checks if a target language is in the supported
languages list. Refactor UefiLib to use this function where appropriate
internally.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Zhao 
---
 MdePkg/Include/Library/UefiLib.h | 16 ++
 MdePkg/Library/UefiLib/UefiLib.c | 59 +---
 2 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/Library/UefiLib.h
b/MdePkg/Include/Library/UefiLib.h
index 1650f30ddbc6..9dd170cbe2bf 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -461,6 +461,22 @@ EfiTestChildHandle (
   IN CONST EFI_GUID *ProtocolGuid
   );
 +/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param  SupportedLanguages  The supported languages
+ * @param  TargetLanguage  The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+  IN CONST CHAR8 *SupportedLanguages,
+  IN CONST CHAR8 *TargetLanguage
+  );
+
 /**
   This function looks up a Unicode string in UnicodeStringTable.
 diff --git a/MdePkg/Library/UefiLib/UefiLib.c
b/MdePkg/Library/UefiLib/UefiLib.c
index daa4af762e62..56281d25fd99 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -640,6 +640,35 @@ EfiTestChildHandle (
   return Status;
 }
 +/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param  SupportedLanguages  The supported languages
+ * @param  TargetLanguage  The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+  IN CONST CHAR8 *SupportedLanguages,
+  IN CONST CHAR8 *TargetLanguage
+  )
+{
+  UINTN Index;
+  while (*SupportedLanguages != 0) {
+for (Index = 0; SupportedLanguages[Index] != 0 &&
SupportedLanguages[Index] != ';'; Index++);
+if ((AsciiStrnCmp(SupportedLanguages, TargetLanguage, Index) == 0)
&& (TargetLanguage[Index] == 0)) {
+  return EFI_SUCCESS;
+}
+SupportedLanguages += Index;
+for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
SupportedLanguages++);
+  }
+
+  return EFI_UNSUPPORTED;
+}
+
 /**
   This function looks up a Unicode string in UnicodeStringTable.
 @@ -800,24 +829,19 @@ LookupUnicodeString2 (
   // Make sure Language is in the set of Supported Languages
   //
   Found = FALSE;
-  while (*SupportedLanguages != 0) {
-if (Iso639Language) {
+  if (Iso639Language) {
+while (*SupportedLanguages != 0) {
   if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
 Found = TRUE;
 break;
   }
   SupportedLanguages += 3;
-} else {
-  for (Index = 0; SupportedLanguages[Index] != 0 &&
SupportedLanguages[Index] != ';'; Index++);
-  if ((AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) &&
(Language[Index] == 0)) {
-Found = TRUE;
-break;
-  }
-  SupportedLanguages += Index;
-  for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
SupportedLanguages++);
 }
+  } else {
+Found = !IsLanguageSupported(Language, SupportedLanguages);
   }
 +
   //
   // If Language is not a member of SupportedLanguages, then return
EFI_UNSUPPORTED
   //
@@ -1099,24 +1123,17 @@ AddUnicodeString2 (
   // Make sure Language is a member of SupportedLanguages
   //
   Found = FALSE;
-  while (*SupportedLanguages != 0) {
-if (Iso639Language) {
+  if (Iso639Language) {
+while (*SupportedLanguages != 0) {
   if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
 Found = TRUE;
 break;
   }
   SupportedLanguages += 3;
-} else {
-  for (Index = 0; SupportedLanguages[Index] != 0 &&
SupportedLanguages[Index] != ';'; Index++);
-  if (AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) {
-Found = TRUE;
-break;
-  }
-  SupportedLanguages += Index;
-  for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
SupportedLanguages++);
 }
+  } else {
+Found = !IsLanguageSupported(Language, SupportedLanguages);
   }
-
   //
   // If Language is not a member of SupportedLanguages, then return
EFI_UNSUPPORTED
   //
-- 
2.21.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46615): https://edk2.groups.io/g/devel/message/46615
Mute This Topic: https://groups.io/mt/33078621/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v5 1/4] MdePkg: Implement SCSI commands for Security Protocol In/Out

2019-08-30 Thread Liming Gao
UefiScsiLib is designed for the convenient usage with SCSI commands. They 
should try to align to UEFI definition. 
If you check current SCSI APIs, their interface matches 
EFI_SCSI_IO_SCSI_REQUEST_PACKET strut. 
So, new added APIs had better match EFI_STORAGE_SECURITY_COMMAND_PROTOCOL. 

For the change in MdePkg\Include\Protocol\ScsiIo.h, where is new definition 
EFI_SCSI_IO_TYPE_WLUN from?

Thanks
Liming
>-Original Message-
>From: Wu, Hao A
>Sent: Friday, August 30, 2019 1:18 PM
>To: Zurcher, Christopher J ;
>devel@edk2.groups.io; Gao, Liming ; Kinney, Michael
>D 
>Cc: Yao, Jiewen ; Wang, Jian J
>
>Subject: RE: [edk2-devel] [PATCH v5 1/4] MdePkg: Implement SCSI commands
>for Security Protocol In/Out
>
>Hello,
>
>Sorry for top-posting.
>
>I was thinking to make the parameters interface match between the
>UefiScsiLib
>API and the EFI Storage Security Command Protocol service, since the
>implementation of the SSC protocol will directly call the UefiScsiLib API.
>
>More specifically, for UefiScsiLib API:
>EFI_STATUS
>EFIAPI
>ScsiSecurityProtocolInCommand (
>  ...
>  IN UINT32  TransferLength,
>  ...
>  IN OUT UINT32  *DataLength
>  )
>
>to match the SSC protocol service:
>typedef
>EFI_STATUS
>(EFIAPI *EFI_STORAGE_SECURITY_RECEIVE_DATA)(
>  ...
>  IN UINTN   PayloadBufferSize,
>  ...
>  OUT UINTN  *PayloadTransferSize
>  )
>
>and for UefiScsiLib API:
>EFI_STATUS
>EFIAPI
>ScsiSecurityProtocolOutCommand (
>  ...
>  IN UINT32  TransferLength,
>  ...
>  )
>
>to match the SSC protocol service:
>typedef
>EFI_STATUS
>(EFIAPI *EFI_STORAGE_SECURITY_SEND_DATA) (
>  ...
>  IN UINTN  PayloadBufferSize,
>  ...
>  )
>
>I am okay with the cast from UINTN to UINT32, as long as we can ensure
>truncation will not happen (which I think should be safe when dealing with
>data transfer with actual devices).
>
>But for casting from UINTN* to UINT32*, I am not sure if this is a
>recommended
>coding style. Maybe within the BIOS perspective, little endian is always the
>case where such cast should work well.
>
>I will leave this open to MdePkg package maintainers for their inputs.
>
>Best Regards,
>Hao Wu
>
>
>> -Original Message-
>> From: Zurcher, Christopher J
>> Sent: Friday, August 30, 2019 8:35 AM
>> To: Wu, Hao A; devel@edk2.groups.io
>> Cc: Yao, Jiewen; Wang, Jian J; Gao, Liming
>> Subject: RE: [edk2-devel] [PATCH v5 1/4] MdePkg: Implement SCSI
>> commands for Security Protocol In/Out
>>
>> I've implemented all the suggested changes except changing the arguments
>> from UINT32 to UINTN. No other functions in UefiScsiLib take UINTN
>> arguments, and since the library is directly packing the CDB, I think it 
>> makes
>> sense to force the caller to provide the correct-size length value. That way
>> there is no ambiguity on what is going to the device.
>> If you agree I will send the updated patchset.
>>
>> Thanks,
>> Christopher Zurcher
>>
>> -Original Message-
>> From: Wu, Hao A
>> Sent: Monday, August 26, 2019 20:03
>> To: devel@edk2.groups.io; Zurcher, Christopher J
>> 
>> Cc: Yao, Jiewen ; Wang, Jian J
>> ; Gao, Liming 
>> Subject: RE: [edk2-devel] [PATCH v5 1/4] MdePkg: Implement SCSI
>> commands for Security Protocol In/Out
>>
>> Hello,
>>
>> Please refer to the below inline comments:
>>
>>
>> > -Original Message-
>> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> > Zurcher, Christopher J
>> > Sent: Friday, August 23, 2019 6:02 AM
>> > To: devel@edk2.groups.io
>> > Cc: Yao, Jiewen; Wang, Jian J; Gao, Liming
>> > Subject: [edk2-devel] [PATCH v5 1/4] MdePkg: Implement SCSI commands
>> > for Security Protocol In/Out
>> >
>> > This patch implements the Security Protocol In and Security Protocol Out
>> > commands in UefiScsiLib to prepare support for the Storage Security
>> > Command Protocol.
>> >
>> > Cc: Jiewen Yao 
>> > Cc: Jian J Wang 
>> > Cc: Liming Gao 
>> > Signed-off-by: Christopher J Zurcher 
>> > ---
>> >  MdePkg/Include/IndustryStandard/Scsi.h   |  48 +++--
>> >  MdePkg/Include/Library/UefiScsiLib.h | 126 +++-
>> >  MdePkg/Include/Protocol/ScsiIo.h |   9 +-
>> >  MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 205 +++-
>> >  4 files changed, 366 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/MdePkg/Include/IndustryStandard/Scsi.h
>> > b/MdePkg/Include/IndustryStandard/Scsi.h
>> > index cbe5709fe5..10d7b49ba7 100644
>> > --- a/MdePkg/Include/IndustryStandard/Scsi.h
>> > +++ b/MdePkg/Include/IndustryStandard/Scsi.h
>> > @@ -1,7 +1,7 @@
>> >  /** @file
>> >Support for SCSI-2 standard
>> >
>> > -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>> > +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>> >SPDX-License-Identifier: BSD-2-Clause-Patent
>> >
>> >  **/
>> > @@ -163,6 +163,12 @@
>> >  #define EFI_SCSI_OP_SEND_MESSAGE10  0x2a
>> >  #define EFI_SCSI_OP_SEND_MESSAGE12  0xaa
>> >
>> > +//
>> > +// Additional commands for Secure Transactions
>> > +//
>> > +#define 

[edk2-devel] [PATCH v5] IntelSiliconPkg-Vtd: A new PMR interface

2019-08-30 Thread Evelyn Wang
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1770

1) IOMMU PMR feature should be generic to support different hardware
architecture. Platforms may request no overlap between PMR regions
and system reserve memory. Create an interface to control PLMR/PHMR
regions. It allows silicon code to adjust PLMR/PHMR region base on
the project needs.

2) DisableDMAr Function Code Optimization
Optimize the flow to follow the VT-d spec requirements.

3) Renamed InitDmar() to InitGlobalVtd()
The oringal function name is misleading

4) A new GetVtdPmrAlignmentLib for silicon code to get
PMR alignment values.

Signed-off-by: Evelyn Wang 
Cc: Jenny Huang 
Cc: More Shih 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 

---
In V2:
1) Fixed the EFIAPI is missing in library API issue
2) Logs will be provided to make sure the backwards compatibility
3) Replaced BIT0 with EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL
4) Renamed GetVtdPmrAlignmentLib to PeiGetVtdPmrAlignmentLib
5) Fixed the indent in IntelVTdPmrPei.c
6) Follow VTd spec to define the data type of the SYSTEM_MEM_INFO_HOB
   Applied few changes coordinately

---
In V3:
1) Fixed the EFIAPI is missing in library API issue
2) Fixed the S3 resume assert

---
In V4:
Fixed the missing EFIAPI in .h file and added few more comments

---
In V5:
In order to align with the future planning,
changed the hob name from SYSTEM_MEM_INFO_HOB to VTD_PMR_INFO_HOB
---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c 
   |  30 +++---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c 
   |   4 ++--
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c  
   |  73 
++---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c  
   |  29 ++---
 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
 |   9 +
 
Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.c
 | 166 
++
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf
   |   5 -
 Silicon/Intel/IntelSiliconPkg/Include/Library/PeiGetVtdPmrAlignmentLib.h   
   |  22 ++
 Silicon/Intel/IntelSiliconPkg/Include/VtdPmrInfoHob.h  
   |  25 +
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  
   |  11 +--
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  
   |   3 ++-
 
Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.inf
   |  32 
 12 files changed, 370 insertions(+), 39 deletions(-)

diff --git a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
index 22bf821d2b..699639ba88 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -309,6 +309,8 @@ DisableDmar (
   UINTN Index;
   UINTN SubIndex;
   UINT32Reg32;
+  UINT32Status;
+  UINT32Command;
 
   for (Index = 0; Index < mVtdUnitNumber; Index++) {
 DEBUG((DEBUG_INFO, ">>DisableDmar() for engine [%d] \n", Index));
@@ -319,9 +321,31 @@ DisableDmar (
 FlushWriteBuffer (Index);
 
 //
-// Disable VTd
+// Disable Dmar
 //
-MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
B_GMCD_REG_SRTP);
+//
+// Set TE (Translation Enable: BIT31) of Global command register to zero
+//
+Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+Status = (Reg32 & 0x96FF);   // Reset the one-shot bits
+Command = (Status & ~B_GMCD_REG_TE);
+MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
Command);
+
+//
+// Poll on TE Status bit of Global status register to become zero
+//
+do {
+  Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+} while ((Reg32 & B_GSTS_REG_TE) == B_GSTS_REG_TE);
+
+//
+// Set SRTP (Set Root Table Pointer: BIT30) of Global command register in 
order to update the root table pointerDisable VTd
+//
+Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 

Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1

2019-08-30 Thread Liming Gao
Mike:
  I add my comments. 

>-Original Message-
>From: r...@edk2.groups.io [mailto:r...@edk2.groups.io] On Behalf Of Michael
>D Kinney
>Sent: Friday, August 30, 2019 4:23 AM
>To: devel@edk2.groups.io; r...@edk2.groups.io
>Subject: [edk2-rfc] [RFC] EDK II Continuous Integration Phase 1
>
>Hello,
>
>This is a proposal for a first step towards continuous
>integration for all TianoCore repositories to help
>improve to quality of commits and automate testing and
>release processes for all EDK II packages and platforms.
>
>This is based on work from a number of EDK II community
>members that have provide valuable input and evaluations.
>
>* Rebecca Cran  Jenkins evaluation
>* Laszlo Ersek  GitLab evaluation
>* Philippe Mathieu-Daudé  GitLab evaluation
>* Sean Brogan  Azure Pipelines and HBFA
>* Bret Barkelew  Azure Pipelines and HBFA
>* Jiewen Yao  HBFA
>
>The following link is a link to an EDK II WIKI page that
>contains a summary of the work to date.  Please provide
>feedback in the EDK II mailing lists.  The WIKI pages will
>be updated with input from the entire EDK II community.
>
>https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Continuous-
>Integration
>
>Proposal
>
>Phase 1 of adding continuous integration is limited to the
>edk2 repository.  Additional repositories will be added later.
>
>The following changes are proposed:
>* Remove EDK II Maintainers write access to edk2 repository.
>  Only EDK II Administrators will continue to have write
>  access, and that should only be used to handle extraordinary
>  events.
>* EDK II Maintainers use a GitHub Pull Request instead of push
>  to commit a patch series to the edk2 repository.  There are
>  no other changes to the development and review process.  The
>  patch series is prepared in an EDK II maintainer branch with
>  all commit message requirements met on each patch in the series.

Will the maintainer manually provide pull request after the patch passes the 
review?
Can the script scan the mail list and auto trig pull request once the patch 
gets 
Reviewed-by or Acked-by from Package maintainers?

>* The edk2 repository only accepts Pull Requests from members
>  of the EDK II Maintainers team.  Pull Requests from anyone else
>  are rejected.
>* Run pre-commit checks using Azure Pipelines

The maintainer manually trig pre-commit check or auto trig pre-commit?
By default, pre-commit should be auto trigged based on pull request. 

>* If all pre-commit checks pass, then the patch series is auto
>  committed.  The result of this commit must match the contents
>  and commit history that would have occurred using the previous
>  push operation.
>* If any pre-commit checks fail, then notify the submitter.

Will Pre-commit check fail send the mail to the patch submitter?
The patch submitter need update the patch and go through review process again. 

>  A typical reason for a failure would be a merge conflict with
>  another pull request that was just processed.
>* Limit pre-commit checks execution time to 10 minutes.
>* Provide on-demand builds to EDK II Maintainers that to allow
>  EDK II Maintainers to submit a branch through for the same
>  set of pre-commit checks without submitting a pull request.
>
>## Pre-Commit Checks in Phase 1
>* Run and pass PatchCheck.py with no errors
>
>=
>
>The following are some additional pre-commit check ideas
>that could be quickly added once the initial version using
>PatchCheck.py is fully functional.  Please provide feedback
>on the ones you like and additional ones you think may
>improve the quality of the commits to the edk2 repository.
>
>## Proposed Pre-Commit Checks in Phase 2
>* Verify Reviewed-by and Acked-by tags are present with
>  correct maintainer email addresses
>* Verify no non-ASCII characters in modified files
>* Verify no binary files in set of modified files

Now, Edk2 has few binary files, like logo.bmp. 
I see one BZ to request logo bmp update. 
(BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2050)
So, we need the exception way for it. 

>* Verify package dependency rules in modified files
>
>## Proposed Pre-Commit Checks in Phase 3
>* Run ECC on modified files
>* Verify modified modules/libs build
>* Run available host based tests (HBFA) against modified
>  modules/libs
>

I request boot test on Emulator and Ovmf in the daily and weekly scope. 
Daily can cover boot to Shell.
Weekly can cover more boot functionality. 

Thanks
Liming
>Best regards,
>
>Mike
>
>
>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46612): https://edk2.groups.io/g/devel/message/46612
Mute This Topic: https://groups.io/mt/33072637/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-