Re: [edk2-devel] Duplicate Files for StandaloneMmDriverEntryPoint.h

2021-02-23 Thread Ard Biesheuvel
On Tue, 23 Feb 2021 at 18:37, Laszlo Ersek  wrote:
>
> Hi Michael,
>
> On 02/22/21 23:11, Michael Kubacki wrote:
> > Is there a particular reason two copies of
> > StandaloneMmDriverEntryPoint.h exist in the edk2 repo?
> >
> > 1. MdePkg
> > https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
> >
> >
> > 2. StandaloneMmPkg
> > https://github.com/tianocore/edk2/blob/master/StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h
> >
> >
> > The only substantial difference (apart from copyright and comment
> > differences) is that the StandaloneMmPkg instance contains a function
> > declaration for EfiMain().
>
> I believe this may have been an omission in commit d6253d2f9a33
> ("StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint
> driver", 2019-03-11).
>
> At that point, both the library class & instance had been migrated to
> MdePkg (commits 7df4764e6a81a and 5866d4992396).
>
> Can you propose a patch (unless I'm wrong, of course)?
>

I think you are correct.

For a patch that deletes

StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h

and any stale references to it that may exist:

Acked-by: Ard Biesheuvel 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72146): https://edk2.groups.io/g/devel/message/72146
Mute This Topic: https://groups.io/mt/80837636/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] Fix wrong information of TigerLake in Readme.md

2021-02-23 Thread Chaganty, Rangasai V
Reviewed-by: Sai Chaganty 

-Original Message-
From: Luo, Heng  
Sent: Tuesday, February 23, 2021 6:05 PM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Desimone, Nathaniel L 

Subject: [PATCH] Fix wrong information of TigerLake in Readme.md

Machine Name of TigerLake is TGL-U DDR4 RVP but no TGL-U LPDDR4 RVP

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3175

Cc: Sai Chaganty 
Cc: Nate DeSimone 
Signed-off-by: Heng Luo 
---
 Platform/Intel/Readme.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md index 
b3b15405af..41d39c8582 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -76,7 +76,7 @@ A UEFI firmware implementation using MinPlatformPkg is 
constructed using the fol
 | RVP 3 | SkyLake, KabyLake, KabyLake Refresh  
  | KabylakeOpenBoardPkg | KabylakeRvp3   | | WHL-U DDR4 RVP
| WhiskeyLake| 
WhiskeylakeOpenBoardPkg  | WhiskeylakeURvp| | CML-U LPDDR3 RVP  
| CometLake V1   | 
CometlakeOpenBoardPkg| CometlakeURvp  |-| TGL-U LPDDR4 RVP  
| TigerLake  | 
TigerlakeOpenBoardPkg| TigerlakeURvp  |+| TGL-U DDR4 RVP
| TigerLake  | 
TigerlakeOpenBoardPkg| TigerlakeURvp  |  *Note: RVP = Reference and 
Validation Platform* -- 
2.24.0.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72145): https://edk2.groups.io/g/devel/message/72145
Mute This Topic: https://groups.io/mt/80868096/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v8 09/10] OvmfPkg/CpuHotplugSmm: do actual CPU hot-eject

2021-02-23 Thread Ankur Arora

On 2021-02-23 1:39 p.m., Laszlo Ersek wrote:

On 02/22/21 08:19, Ankur Arora wrote:

Add logic in EjectCpu() to do the actual the CPU ejection.

On the BSP, ejection happens by first selecting the CPU via
its QemuSelector and then sending the QEMU "eject" command.
QEMU in-turn signals the remote VCPU thread which context-switches
the CPU out of the SMI handler.

Meanwhile the CPU being ejected, waits around in its holding
area until it is context-switched out. Note that it is possible
that a slow CPU gets ejected before it reaches the wait loop.
However, this would never happen before it has executed the
"AllCpusInSync" loop in SmiRendezvous().
It can mean that an ejected CPU does not execute code after
that point but given that the CPU state will be destroyed by
QEMU, the missed cleanup is no great loss.

Cc: Laszlo Ersek 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Igor Mammedov 
Cc: Boris Ostrovsky 
Cc: Aaron Young 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora 
---

Notes:
 Addresses the following reviewing comments from v6:
 (1) s/CpuEject/EjectCpu/g
 (2,2a,2c) Get rid of eject-worker and related.
 (2b,2d) Use the PlatformSmmBspElection() logic to find out IsBSP.
 (3,3b) Use CPU_HOT_EJECT_DATA->QemuSelector instead of ApicIdMap to
  do the actual ejection.
 (4,5a,5b) Fix the format etc in the final unplugged log message
 () Also as discussed elsewhere document the ordering requirements for
  mCpuHotEjectData->QemuSelector[] and mCpuHotEjectData->Handler.
 () [from patch 2] Move definition of QEMU_CPUHP_STAT_EJECTED to this
  patch.
 () s/QEMU_CPUHP_STAT_EJECTED/QEMU_CPUHP_STAT_EJECT/

  OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h  |   1 +
  OvmfPkg/CpuHotplugSmm/CpuHotplug.c | 127 +++--
  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  |  31 +
  3 files changed, 152 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h 
b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
index 2ec7a107a64d..d0e83102c13f 100644
--- a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
+++ b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
@@ -34,6 +34,7 @@
  #define QEMU_CPUHP_STAT_ENABLEDBIT0
  #define QEMU_CPUHP_STAT_INSERT BIT1
  #define QEMU_CPUHP_STAT_REMOVE BIT2
+#define QEMU_CPUHP_STAT_EJECT  BIT3
  #define QEMU_CPUHP_STAT_FW_REMOVE  BIT4
  
  #define QEMU_CPUHP_RW_CMD_DATA   0x8

diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c 
b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
index 851e2b28aad9..0484be8fe43c 100644
--- a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
+++ b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
@@ -18,6 +18,7 @@
  #include  // CPU_HOT_EJECT_DATA
  #include // EFI_MM_CPU_IO_PROTOCOL
  #include   // EFI_SMM_CPU_SERVICE_PROTOCOL
+#include  // MSR_IA32_APIC_BASE_REGISTER
  #include// EFI_STATUS
  
  #include "ApicId.h"  // APIC_ID

@@ -191,12 +192,39 @@ RevokeNewSlot:
  }
  
  /**

+  EjectCpu needs to know the BSP at SMI exit at a point when
+  some of the EFI_SMM_CPU_SERVICE_PROTOCOL state has been torn
+  down.
+  Reuse the logic from OvmfPkg::PlatformSmmBspElection() to
+  do that.
+
+  @param[in] ProcessorNum  ProcessorNum denotes the processor handle number
+   in EFI_SMM_CPU_SERVICE_PROTOCOL.
+**/
+STATIC
+BOOLEAN
+CheckIfBsp (
+  IN UINTN ProcessorNum
+  )


(1a) Please remove the ProcessorNum parameter -- comment and parameter
list alike --; it's useless. In the parameter list, just replace the
line's contents with "VOID".


Heh. Yeah, I'm not certain why I added that.
 

(1b) Additionally, please state:

   @retval TRUE   If the CPU executing this function is the BSP.

   @retval FALSE  If the CPU executing this function is an AP.



Will add.






+{
+  MSR_IA32_APIC_BASE_REGISTER ApicBaseMsr;
+  BOOLEAN IsBsp;


(2) "IsBsp" should line up with "ApicBaseMsr".



+
+  ApicBaseMsr.Uint64 = AsmReadMsr64 (MSR_IA32_APIC_BASE);
+  IsBsp = (BOOLEAN)(ApicBaseMsr.Bits.BSP == 1);
+  return IsBsp;
+}
+
+/**
CPU Hot-eject handler, called from SmmCpuFeaturesRendezvousExit()
on each CPU at exit from SMM.
  
-  If, the executing CPU is not being ejected, nothing to be done.

+  If, the executing CPU is neither the BSP, nor being ejected, nothing
+  to be done.
If, the executing CPU is being ejected, wait in a halted loop
until ejected.
+  If, the executing CPU is the BSP, set QEMU CPU status to eject
+  for CPUs being ejected.
  
@param[in] ProcessorNum  ProcessorNum denotes the CPU exiting SMM,

 and will be used as an index into
@@ -211,9 +239,99 @@ EjectCpu (
)
  {
UINT64 QemuSelector;
+  BOOLEAN IsBsp;
  
+  IsBsp = CheckIfBsp (ProcessorNum);

+
+  //
+  // mCpuHotEjectData->QemuSelectorMap[ProcessorNum

Re: [edk2-devel] [PATCH edk2-platforms v1 0/2] TigerlakeOpenBoardPkg: Fix build error with GCC5

2021-02-23 Thread Heng Luo
Thanks Takuto Naito!

For the series..
Reviewed-by: Heng Luo 

> -Original Message-
> From: Takuto Naito 
> Sent: Wednesday, February 24, 2021 9:38 AM
> To: devel@edk2.groups.io
> Cc: Takuto Naito ; Chaganty, Rangasai V
> ; Desimone, Nathaniel L
> ; Luo, Heng 
> Subject: [PATCH edk2-platforms v1 0/2] TigerlakeOpenBoardPkg: Fix build
> error with GCC5
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224
> 
> Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
> These build errors occur only with DEBUG target because
> RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable", but
> DEBUG_GCC5_X64_CC_FLAGS doesn't.
> 
> https://github.com/naitaku/edk2-platforms/tree/tigerlake_fix_unused-but-
> set-variable_v1
> 
> Cc: Sai Chaganty 
> Cc: Nate DeSimone 
> Cc: Heng Luo 
> 
> Takuto Naito (2):
>   TigerlakeSiliconPkg: Fix build error with GCC5
>   TigerlakeOpenBoardPkg: Fix build error with GCC5
> 
>  .../Library/BasePlatformHookLib/BasePlatformHookLib.c | 8 
>  .../Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c  | 2 ++
>  .../LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c  | 2 --
>  .../Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c  | 5 -
>  .../Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c | 2 --
>  5 files changed, 2 insertions(+), 17 deletions(-)
> 
> --
> 2.30.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72143): https://edk2.groups.io/g/devel/message/72143
Mute This Topic: https://groups.io/mt/80867658/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2-platforms v1 2/2] TigerlakeOpenBoardPkg: Fix build error with GCC5

2021-02-23 Thread Heng Luo
Reviewed-by: Heng Luo 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Takuto
> Naito
> Sent: Wednesday, February 24, 2021 9:38 AM
> To: devel@edk2.groups.io
> Cc: Takuto Naito ; Chaganty, Rangasai V
> ; Desimone, Nathaniel L
> ; Luo, Heng 
> Subject: [edk2-devel] [PATCH edk2-platforms v1 2/2] TigerlakeOpenBoardPkg:
> Fix build error with GCC5
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224
> 
> Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
> These build errors occur only with DEBUG target because
> RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable", but
> DEBUG_GCC5_X64_CC_FLAGS doesn't.
> 
> Cc: Sai Chaganty 
> Cc: Nate DeSimone 
> Cc: Heng Luo 
> Signed-off-by: Takuto Naito 
> ---
>  .../Library/BasePlatformHookLib/BasePlatformHookLib.c | 8 
>  .../Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c  | 2 ++
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git
> a/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/Base
> PlatformHookLib.c
> b/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/Bas
> ePlatformHookLib.c
> index cc5337698b..0baee8795d 100644
> ---
> a/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/Base
> PlatformHookLib.c
> +++
> b/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/B
> +++ asePlatformHookLib.c
> @@ -182,14 +182,6 @@ PlatformHookSerialPortInitialize (
>VOID
>)
>  {
> -  UINT16  IndexPort;
> -  UINT16  DataPort;
> -  UINT8   Index;
> -
> -  IndexPort = 0;
> -  DataPort = 0;
> -  Index = 0;
> -
>//
>// Enable I/O decoding for COM1(3F8h-3FFh), COM2(2F8h-2FFh), I/O port
> 2Eh/2Fh, 4Eh/4Fh, 60h/64Fh and 62h/66h.
>//
> diff --git
> a/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLi
> b/PeiTigerlakeURvpInitPreMemLib.c
> b/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLi
> b/PeiTigerlakeURvpInitPreMemLib.c
> index 2ad229c1cd..0bba41e6d4 100644
> ---
> a/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLi
> b/PeiTigerlakeURvpInitPreMemLib.c
> +++
> b/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardIn
> +++ itLib/PeiTigerlakeURvpInitPreMemLib.c
> @@ -393,6 +393,7 @@ TigerlakeURvpInitPreMem (
>/// Performing PlatformInitPreMemCallBack after PeiReadOnlyVariable2 PPI
> produced
>///
>Status = PeiServicesNotifyPpi (&mPreMemNotifyList);
> +  ASSERT_EFI_ERROR (Status);
> 
>///
>/// After code reorangized, memorycallback will run because the PPI is
> already @@ -400,6 +401,7 @@ TigerlakeURvpInitPreMem (
>/// done before.
>///
>Status = PeiServicesNotifyPpi (&mMemDiscoveredNotifyList);
> +  ASSERT_EFI_ERROR (Status);
> 
>DEBUG ((DEBUG_INFO, "TigerlakeURvpInitPreMem End!\n"));
> 
> --
> 2.30.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72142): https://edk2.groups.io/g/devel/message/72142
Mute This Topic: https://groups.io/mt/80867667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2-platforms v1 1/2] TigerlakeSiliconPkg: Fix build error with GCC5

2021-02-23 Thread Heng Luo
Reviewed-by: Heng Luo 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Takuto
> Naito
> Sent: Wednesday, February 24, 2021 9:38 AM
> To: devel@edk2.groups.io
> Cc: Takuto Naito ; Chaganty, Rangasai V
> ; Desimone, Nathaniel L
> ; Luo, Heng 
> Subject: [edk2-devel] [PATCH edk2-platforms v1 1/2] TigerlakeSiliconPkg: Fix
> build error with GCC5
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224
> 
> Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
> These build errors occur only with DEBUG target because
> RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable", but
> DEBUG_GCC5_X64_CC_FLAGS doesn't.
> 
> Cc: Sai Chaganty 
> Cc: Nate DeSimone 
> Cc: Heng Luo 
> Signed-off-by: Takuto Naito 
> ---
>  .../PcieRp/LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c  | 2 --
>   .../IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c | 5 -
>  .../Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c| 2 --
>  3 files changed, 9 deletions(-)
> 
> diff --git
> a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientR
> pLib/PcieClientRpLib.c
> b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientR
> pLib/PcieClientRpLib.c
> index 15d295a573..231cb367bc 100644
> ---
> a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientR
> pLib/PcieClientRpLib.c
> +++ b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/Pc
> +++ ieClientRpLib/PcieClientRpLib.c
> @@ -104,12 +104,10 @@ ConfigureRpLtrOverride (
>UINT32   OvrEn;
>UINT32   OvrVal;
>BOOLEAN  IsCpuPcie;
> -  UINT32   LtrCfgLock;
> 
>IsCpuPcie = FALSE;
>OvrEn = 0;
>OvrVal = 0;
> -  LtrCfgLock = 0;
> 
>if (DevNum == SA_PEG0_DEV_NUM || DevNum == SA_PEG3_DEV_NUM) {
>  IsCpuPcie = TRUE;
> diff --git
> a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/
> DxeVtdInitLib.c
> b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/
> DxeVtdInitLib.c
> index faac07c45d..e88abe550f 100644
> ---
> a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/
> DxeVtdInitLib.c
> +++ b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVt
> +++ dInitLib/DxeVtdInitLib.c
> @@ -313,8 +313,6 @@ DmarTableUpdate (
>UINTN   Offset;
>UINTN   StructureLen;
>UINT64  McD0BaseAddress;
> -  UINT32  GttMmAdr;
> -  UINT64  McD2BaseAddress;
>UINT16  IgdMode;
>UINT16  GttMode;
>UINT32  IgdMemSize;
> @@ -381,9 +379,6 @@ DmarTableUpdate (
>  GttMemSize = (1 << GttMode) * (1024) * (1024);
>}
> 
> -  McD2BaseAddress = PCI_SEGMENT_LIB_ADDRESS (SA_SEG_NUM,
> IGD_BUS_NUM, IGD_DEV_NUM, IGD_FUN_NUM, 0);
> -  GttMmAdr = (PciSegmentRead32 (McD2BaseAddress +
> R_SA_IGD_GTTMMADR)) & 0xFFF0;
> -
>DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionBaseAddress   =
> (PciSegmentRead32 (McD0BaseAddress + R_SA_BGSM) & ~(0x01));
>DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionLimitAddress  =
> DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionBaseAddress +
> IgdMemSize + GttMemSize - 1;
>DEBUG ((DEBUG_INFO, "RMRR Base  address IGD %016lX\n", DmarTable-
> >RmrrIgd.RmrrHeader.ReservedMemoryRegionBaseAddress));
> diff --git
> a/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelpe
> rClient.c
> b/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelpe
> rClient.c
> index 7693e76683..3adc05ce89 100644
> ---
> a/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelpe
> rClient.c
> +++ b/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiH
> +++ elperClient.c
> @@ -29,8 +29,6 @@ GetPcieRpNumber (
>OUT UINTN   *RpNumber
>)
>  {
> -  UINT64  RpBase;
> -  RpBase = PCI_SEGMENT_LIB_ADDRESS (SA_SEG_NUM, SA_MC_BUS, RpDev,
> RpFun, 0);
>GetPchPcieRpNumber (RpDev, RpFun, RpNumber);  }
> 
> --
> 2.30.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72141): https://edk2.groups.io/g/devel/message/72141
Mute This Topic: https://groups.io/mt/80867664/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] Fix wrong information of TigerLake in Readme.md

2021-02-23 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

> -Original Message-
> From: Luo, Heng 
> Sent: Tuesday, February 23, 2021 6:05 PM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Desimone,
> Nathaniel L 
> Subject: [PATCH] Fix wrong information of TigerLake in Readme.md
> 
> Machine Name of TigerLake is TGL-U DDR4 RVP but no TGL-U LPDDR4 RVP
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3175
> 
> Cc: Sai Chaganty 
> Cc: Nate DeSimone 
> Signed-off-by: Heng Luo 
> ---
>  Platform/Intel/Readme.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md index
> b3b15405af..41d39c8582 100644
> --- a/Platform/Intel/Readme.md
> +++ b/Platform/Intel/Readme.md
> @@ -76,7 +76,7 @@ A UEFI firmware implementation using MinPlatformPkg
> is constructed using the fol
>  | RVP 3 | SkyLake, KabyLake, KabyLake 
> Refresh|
> KabylakeOpenBoardPkg | KabylakeRvp3   | | WHL-U DDR4 RVP
> | WhiskeyLake| WhiskeylakeOpenBoardPkg  |
> WhiskeylakeURvp| | CML-U LPDDR3 RVP  | CometLake V1
> | CometlakeOpenBoardPkg| CometlakeURvp  |-| TGL-U LPDDR4 RVP
> | TigerLake  | TigerlakeOpenBoardPkg| 
> TigerlakeURvp
> |+| TGL-U DDR4 RVP| TigerLake 
>  |
> TigerlakeOpenBoardPkg| TigerlakeURvp  |  *Note: RVP = Reference
> and Validation Platform* --
> 2.24.0.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72140): https://edk2.groups.io/g/devel/message/72140
Mute This Topic: https://groups.io/mt/80868096/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2-platforms v1 0/2] TigerlakeOpenBoardPkg: Fix build error with GCC5

2021-02-23 Thread Nate DeSimone
Thank You Takuto!

For the series... Reviewed-by: Nate DeSimone 

> -Original Message-
> From: Takuto Naito 
> Sent: Tuesday, February 23, 2021 5:38 PM
> To: devel@edk2.groups.io
> Cc: Takuto Naito ; Chaganty, Rangasai V
> ; Desimone, Nathaniel L
> ; Luo, Heng 
> Subject: [PATCH edk2-platforms v1 0/2] TigerlakeOpenBoardPkg: Fix build
> error with GCC5
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224
> 
> Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
> These build errors occur only with DEBUG target because
> RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable", but
> DEBUG_GCC5_X64_CC_FLAGS doesn't.
> 
> https://github.com/naitaku/edk2-platforms/tree/tigerlake_fix_unused-but-
> set-variable_v1
> 
> Cc: Sai Chaganty 
> Cc: Nate DeSimone 
> Cc: Heng Luo 
> 
> Takuto Naito (2):
>   TigerlakeSiliconPkg: Fix build error with GCC5
>   TigerlakeOpenBoardPkg: Fix build error with GCC5
> 
>  .../Library/BasePlatformHookLib/BasePlatformHookLib.c | 8 
>  .../Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c  | 2 ++
>  .../LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c  | 2 --
>  .../Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c  | 5 -
>  .../Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c | 2 --
>  5 files changed, 2 insertions(+), 17 deletions(-)
> 
> --
> 2.30.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72139): https://edk2.groups.io/g/devel/message/72139
Mute This Topic: https://groups.io/mt/80867658/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 02/23/2021 6:30pm-7:30pm #cal-reminder

2021-02-23 Thread devel@edk2.groups.io Calendar
*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Tuesday, 23 February 2021, 6:30pm to 7:30pm, (GMT-08:00) America/Los 
Angeles

*Where:* 
https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd010e1e6d43a6f6c65f45

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1046510 )

*Organizer:* Liming Gao gaolim...@byosoft.com.cn ( 
gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

*Description:*

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd010e1e6d43a6f6c65f45

Wednesday, Jan 20, 2021 10:30 am | 50 minutes | (UTC+08:00) Beijing, Chongqing, 
Hong Kong, Urumqi

Occurs every Wednesday effective 1/20/2021 from 10:30 AM to 11:20 AM, 
(UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Meeting number: 126 867 1239

Password: ZhqYQunw246 (94797869 from video systems)

d8edc6c9604344b08f727b4bf054eaac_20210120T023000Z

Join by video system

Dial 1268671...@meetingsamer34.webex.com

You can also dial 173.243.2.68 and enter your meeting number.

Join by phone

Use VoIP only


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72138): https://edk2.groups.io/g/devel/message/72138
Mute This Topic: https://groups.io/mt/80868346/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] * ShellPkg: add the support to show Contained Element Count, Contained Element Record Length and Contained Elements

2021-02-23 Thread Mars CC Lin
Hi Gao,

I've attach the patch to the bugzilla. thanks for the suggestion.

Mars


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72137): https://edk2.groups.io/g/devel/message/72137
Mute This Topic: https://groups.io/mt/80003667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH] Fix wrong information of TigerLake in Readme.md

2021-02-23 Thread Heng Luo
Machine Name of TigerLake is TGL-U DDR4 RVP but no TGL-U LPDDR4 RVP

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3175

Cc: Sai Chaganty 
Cc: Nate DeSimone 
Signed-off-by: Heng Luo 
---
 Platform/Intel/Readme.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md
index b3b15405af..41d39c8582 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -76,7 +76,7 @@ A UEFI firmware implementation using MinPlatformPkg is 
constructed using the fol
 | RVP 3 | SkyLake, KabyLake, KabyLake Refresh  
  | KabylakeOpenBoardPkg | KabylakeRvp3   |
 | WHL-U DDR4 RVP| WhiskeyLake  
  | WhiskeylakeOpenBoardPkg  | WhiskeylakeURvp|
 | CML-U LPDDR3 RVP  | CometLake V1 
  | CometlakeOpenBoardPkg| CometlakeURvp  |
-| TGL-U LPDDR4 RVP  | TigerLake
  | TigerlakeOpenBoardPkg| TigerlakeURvp  |
+| TGL-U DDR4 RVP| TigerLake
  | TigerlakeOpenBoardPkg| TigerlakeURvp  |
 
 *Note: RVP = Reference and Validation Platform*
 
-- 
2.24.0.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72136): https://edk2.groups.io/g/devel/message/72136
Mute This Topic: https://groups.io/mt/80868096/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB memory WA

2021-02-23 Thread Ni, Ray
Yes! It’s a bug in CpuDxe. I agree with your proposed fix.
3233 – CpuDxe may allocate above 4GB memory for GDT 
(tianocore.org) was 
submitted to capture the potential bug.




From: devel@edk2.groups.io  On Behalf Of Jeff Fan
Sent: Tuesday, February 23, 2021 1:44 PM
To: devel@edk2.groups.io; Ni, Ray ; Ma, Maurice 
; Patrick Rudolph ; Dong, 
Guo ; Dong, Eric 
Cc: You, Benjamin 
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA

Ray,

BSP's GDT table is setup in CpuDxe and then MpInitLib re-uses BSP's GDT table 
for APs.

1, UefiCpuPkg\CpuDxe:
  gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
  .
  gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;

2, UefiCpuPkg\Library\MpInitLib\MpLib.c:
  //
  // Get the BSP's data of GDT and IDT
  //
  AsmReadGdtr ((IA32_DESCRIPTOR *) &ExchangeInfo->GdtrProfile);
  AsmReadIdtr ((IA32_DESCRIPTOR *) &ExchangeInfo->IdtrProfile);

3, UefiCpuPkg\Library\MpInitLib\X64\MpFuncs.nasm:
movsi, GdtrLocation
o32 lgdt   [cs:si]

movsi, IdtrLocation
o32 lidt   [cs:si]

In CpuDxe, Typecasting gdt to UINT32 is one assumption that GDT table is under 
4G space.  Thus, we cannot use AllocateRuntimePool (), instead we should use 
AllocatePages() to make sure GDT table under 4GB space.
  gdt = 0x;
  Status = gBS->AllocatePages (
  AllocateMaxAddress,
  EfiRuntimeServicesData,
  EFI_SIZE_TO_PAGES (sizeof (GdtTemplate) + 8),
  &gdt
  );

Thanks,
Jeff

From: Ni, Ray
Date: 2021-02-23 13:21
To: devel@edk2.groups.io; 
fanjianf...@byosoft.com.cn; Ma, 
Maurice; Patrick 
Rudolph; Dong, 
Guo; Dong, Eric
CC: You, Benjamin
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA
“But we could allocate room under 4G for GDT table directly in CpuDxe.”
The GDT pre-allocated is re-used by AP. Why do you suggest CpuDxe allocate GDT?

Thanks,
Ray

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Jeff Fan
Sent: Tuesday, February 23, 2021 11:43 AM
To: devel@edk2.groups.io; Ni, Ray 
mailto:ray...@intel.com>>; Ma, Maurice 
mailto:maurice...@intel.com>>; Patrick Rudolph 
mailto:patrick.rudo...@9elements.com>>; Dong, 
Guo mailto:guo.d...@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>
Cc: devel@edk2.groups.io; You, Benjamin 
mailto:benjamin@intel.com>>
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA

Ray,

Yes. You are right. Acutally, x64 IDT table cannot work correctly on protected 
mode. :-)

But for GDT location, I agree it should be located under 4G space to support AP 
mode changing.  But we could allocate room under 4G for GDT table directly in 
CpuDxe.

Thanks,
Jeff


From: Ni, Ray
Date: 2021-02-23 10:52
To: fanjianf...@byosoft.com.cn; 
devel; Ma, Maurice; 
Patrick Rudolph; Dong, 
Guo; Dong, Eric
CC: devel@edk2.groups.io; You, 
Benjamin
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA
Jeff,
You are right that BSP’s GDT and IDT tables are under 4G memory.

It’s because when AP wakes up, it needs the GDT for entering protected mode. AP 
cannot access above 4G memory without entering to long mode.

I do agree that the 64bit IDT is not proper for AP when entering protected 
mode. As long as there is no exception in the short time frame (load 64bit IDT, 
before entering long mode), it’s still ok.

Thanks,
Ray

From: fanjianf...@byosoft.com.cn 
mailto:fanjianf...@byosoft.com.cn>>
Sent: Tuesday, February 23, 2021 8:50 AM
To: devel mailto:devel@edk2.groups.io>>; Ma, Maurice 
mailto:maurice...@intel.com>>; Patrick Rudolph 
mailto:patrick.rudo...@9elements.com>>; Dong, 
Guo mailto:guo.d...@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Cc: devel@edk2.groups.io; You, Benjamin 
mailto:benjamin@intel.com>>
Subject: Re: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 
4GB memory WA

we will save the current BSP's GDT and IDT for APs at first time APs are waken 
by BSP as below. APs will start from real mode to protected mode and then to 
long mode. During protected mode, BSP's GDT/IDT table are working on APs.

In UefiCpuPkg\Library\MpInitLib\MpLib.c,
  //

Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition and null instance

2021-02-23 Thread Kun Qin
Hi Jiewen,

I agree with your  assessment that it could have a PEI and potentially MM 
instance. Will remove the prefix and change them to `MmUnblockMemoryLib` in v3 
patches. Thanks for the input.

Regards,
Kun

From: Yao, Jiewen
Sent: Tuesday, February 23, 2021 17:33
To: Wu, Hao A; Kun Qin; 
devel@edk2.groups.io; 
gaoliming; Kinney, Michael 
D; Liu, 
Zhiguang
Cc: Wang, Jian J; Dong, 
Eric; Ni, Ray; Yao, 
Jiewen
Subject: Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

I feel the name is confusing.

The class name is DxeMmUnblockMemoryLib. But actually, this is not related to 
DXE phase.

I believe, it is also applicable to PEI phase, if we have a PEI instance. 
Please correct me if I am wrong.
Also, we can have SMM instance, right?

If that is true, then I prefer to remove Dxe prefix.

From: Wu, Hao A 
Sent: Wednesday, February 24, 2021 9:27 AM
To: Kun Qin ; devel@edk2.groups.io; Yao, Jiewen 
; gaoliming ; Kinney, Michael D 
; Liu, Zhiguang 
Cc: Wang, Jian J ; Dong, Eric ; Ni, 
Ray 
Subject: RE: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Thanks Kun,

For putting the new library in MdePkg, I am not sure whether this is a similar 
case to SmmMemLib.
I looped Jiewen, Liming and Mike to check if they have comments on this.

Best Regards,
Hao Wu

From: Kun Qin mailto:ku...@outlook.com>>
Sent: Wednesday, February 24, 2021 3:30 AM
To: devel@edk2.groups.io; Wu, Hao A 
mailto:hao.a...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>; gaoliming 
mailto:gaolim...@byosoft.com.cn>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Liu, Zhiguang 
mailto:zhiguang@intel.com>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>; Dong, 
Eric mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: RE: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hi Hao,

Thanks for the suggestion. I can move the library to MdePkg similar to 
SmmMemLib and add the change for OVMF.

Liming/Zhiguang,

I am happy to prepare patches to cover the dependency change in ed2-platform in 
a separate patch series. But please let me know if you would like to proceed 
otherwise.

Thanks,
Kun

From: Wu, Hao A
Sent: Monday, February 22, 2021 17:42
To: Kun Qin; 
devel@edk2.groups.io; Yao, 
Jiewen; 
gaoliming; Kinney, Michael 
D; Liu, 
Zhiguang
Cc: Wang, Jian J; Dong, 
Eric; Ni, Ray
Subject: Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hello Kun,

Sorry for the delayed response.

Except for missing the UNI file for the newly added library, I do not have 
other comment for the implementation at this moment.
But I am wondering if this library can be added into the MdePkg as the case for 
MdePkg\Library\SmmMemLib\
I have looped in Jiewen, Liming and Mike for comments.

Also, since:
* New library dependency for VariableSmmRuntimeDxe.inf
* INF file separation and new library dependency in Tcg2Smm
I think the series needs to prepare the changes for platforms under edk2 (OVMF) 
and edk2-platforms repositories that consume the above 2 modules.
I am not exactly sure on how this should be handled within edk2-platforms, so I 
added Liming and Zhiguang here for comments.

Best Regards,
Hao Wu

From: Kun Qin mailto:ku...@outlook.com>>
Sent: Tuesday, February 23, 2021 6:15 AM
To: devel@edk2.groups.io; Wu, Hao A 
mailto:hao.a...@intel.com>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>; Dong, 
Eric mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>
Subject: RE: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added 
definition and null instance

Hi Hao,

The patch series was resent with intended usage in VariableRuntime and Tcg2 
drivers. Could you please provide feedback on them? Any input is appreciated.

Regards,
Kun

From: Kun Qin
Sent: Tuesday, February 9, 2021 17:25
To: devel@edk2.groups.io
Cc: Jian J Wang; Hao A 
Wu; Eric Dong; Ray 
Ni; Jiewen Yao
Subject: [PATCH v2 1/6] MdeModulePkg: DxeMmUn

Re: [edk2-devel] [PATCH v2 5/6] SecurityPkg: Tcg2Smm: Added support for Standalone Mm

2021-02-23 Thread Kun Qin
Hi Jiewen,

This is essentially following the example of VariableStandaloneMm model here:
StandaloneMmPkg/Library: Install Variable Arch Protocol · 
tianocore/edk2@326598e 
(github.com)

The intended usage for this library, in the context of Standalone MM, is to 
link this library to the MM IPL driver (or any other drivers that has a 
dependency on gEfiMmCommunication2ProtocolGuid), which will make sure MM 
communicate is ready to use (and all MM drivers dispatched) before DXE core 
dispatch Tcg2Acpi driver. I could add an example like below in the commit 
message if you think that will help on the intended usage:
```
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf {

  NULL| SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.inf
  }
```

Or if you have any other ideas on making sure of the loading order, please let 
me know as well.

Thanks,
Kun

From: Yao, Jiewen
Sent: Tuesday, February 23, 2021 17:26
To: Kun Qin; 
devel@edk2.groups.io
Cc: Wang, Jian J; Zhang, 
Qi1; Kumar, Rahul1
Subject: Re: [edk2-devel] [PATCH v2 5/6] SecurityPkg: Tcg2Smm: Added support 
for Standalone Mm

I am not sure if Tcg2MmDependencyLib is the best solution.

It seems NULL lib instance. But I am not sure how it is used.

Can we have an example in SecurityPkg.dsc?



> -Original Message-
> From: Kun Qin 
> Sent: Wednesday, February 10, 2021 9:25 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 
> Subject: [PATCH v2 5/6] SecurityPkg: Tcg2Smm: Added support for Standalone
> Mm
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=3169
>
> This change added Standalone MM instance of Tcg2. The notify function for
> Standalone MM instance is left empty.
>
> A designated dependency library was created for DXE drivers to link as an
> anonymous library.
>
> Lastly, the support of CI build for Tcg2 Standalone MM module is added.
>
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
>
> Signed-off-by: Kun Qin 
> ---
>
> Notes:
> v2:
> - Newly added.
>
>  SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c   | 48
> 
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c  | 71
> ++
>  SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.inf | 39
> ++
>  SecurityPkg/SecurityPkg.ci.yaml |  1 +
>  SecurityPkg/SecurityPkg.dec |  1 +
>  SecurityPkg/SecurityPkg.dsc | 10 +++
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.inf| 77
> 
>  7 files changed, 247 insertions(+)
>
> diff --git
> a/SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c
> b/SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c
> new file mode 100644
> index ..12b23813dce1
> --- /dev/null
> +++ b/SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c
> @@ -0,0 +1,48 @@
> +/** @file
> +  Runtime DXE part corresponding to StandaloneMM Tcg2 module.
> +
> +This module installs gTcg2MmSwSmiRegisteredGuid to notify readiness of
> +StandaloneMM Tcg2 module.
> +
> +Copyright (c) 2019 - 2021, Arm Ltd. All rights reserved.
> +Copyright (c) Microsoft Corporation.
> +
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +/**
> +  The constructor function installs gTcg2MmSwSmiRegisteredGuid to notify
> +  readiness of StandaloneMM Tcg2 module.
> +
> +  @param  ImageHandle   The firmware allocated handle for the EFI image.
> +  @param  SystemTable   A pointer to the Management mode System Table.
> +
> +  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +Tcg2MmDependencyLibConstructor (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *SystemTable
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_HANDLEHandle;
> +
> +  Handle = NULL;
> +  Status = gBS->InstallProtocolInterface (
> +  &Handle,
> +  &gTcg2MmSwSmiRegisteredGuid,
> +  EFI_NATIVE_INTERFACE,
> +  NULL
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +  return EFI_SUCCESS;
> +}
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
> new file mode 100644
> index ..9e0095efbc5e
> --- /dev/null
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
> @@ -0,0 +1,71 @@
> +/** @file
> +  TCG2 Standalone MM driver that updates TPM2 items in ACPI table and

[edk2-devel] [PATCH edk2-platforms v1 2/2] TigerlakeOpenBoardPkg: Fix build error with GCC5

2021-02-23 Thread Takuto Naito
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224

Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
These build errors occur only with DEBUG target because
RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable",
but DEBUG_GCC5_X64_CC_FLAGS doesn't.

Cc: Sai Chaganty 
Cc: Nate DeSimone 
Cc: Heng Luo 
Signed-off-by: Takuto Naito 
---
 .../Library/BasePlatformHookLib/BasePlatformHookLib.c | 8 
 .../Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c  | 2 ++
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git 
a/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/BasePlatformHookLib.c
 
b/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/BasePlatformHookLib.c
index cc5337698b..0baee8795d 100644
--- 
a/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/BasePlatformHookLib.c
+++ 
b/Platform/Intel/TigerlakeOpenBoardPkg/Library/BasePlatformHookLib/BasePlatformHookLib.c
@@ -182,14 +182,6 @@ PlatformHookSerialPortInitialize (
   VOID
   )
 {
-  UINT16  IndexPort;
-  UINT16  DataPort;
-  UINT8   Index;
-
-  IndexPort = 0;
-  DataPort = 0;
-  Index = 0;
-
   //
   // Enable I/O decoding for COM1(3F8h-3FFh), COM2(2F8h-2FFh), I/O port 
2Eh/2Fh, 4Eh/4Fh, 60h/64Fh and 62h/66h.
   //
diff --git 
a/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c
 
b/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c
index 2ad229c1cd..0bba41e6d4 100644
--- 
a/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c
+++ 
b/Platform/Intel/TigerlakeOpenBoardPkg/TigerlakeURvp/Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c
@@ -393,6 +393,7 @@ TigerlakeURvpInitPreMem (
   /// Performing PlatformInitPreMemCallBack after PeiReadOnlyVariable2 PPI 
produced
   ///
   Status = PeiServicesNotifyPpi (&mPreMemNotifyList);
+  ASSERT_EFI_ERROR (Status);
 
   ///
   /// After code reorangized, memorycallback will run because the PPI is 
already
@@ -400,6 +401,7 @@ TigerlakeURvpInitPreMem (
   /// done before.
   ///
   Status = PeiServicesNotifyPpi (&mMemDiscoveredNotifyList);
+  ASSERT_EFI_ERROR (Status);
 
   DEBUG ((DEBUG_INFO, "TigerlakeURvpInitPreMem End!\n"));
 
-- 
2.30.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72132): https://edk2.groups.io/g/devel/message/72132
Mute This Topic: https://groups.io/mt/80867667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH edk2-platforms v1 1/2] TigerlakeSiliconPkg: Fix build error with GCC5

2021-02-23 Thread Takuto Naito
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224

Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
These build errors occur only with DEBUG target because
RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable",
but DEBUG_GCC5_X64_CC_FLAGS doesn't.

Cc: Sai Chaganty 
Cc: Nate DeSimone 
Cc: Heng Luo 
Signed-off-by: Takuto Naito 
---
 .../PcieRp/LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c  | 2 --
 .../IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c | 5 -
 .../Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c| 2 --
 3 files changed, 9 deletions(-)

diff --git 
a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c
 
b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c
index 15d295a573..231cb367bc 100644
--- 
a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c
+++ 
b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c
@@ -104,12 +104,10 @@ ConfigureRpLtrOverride (
   UINT32   OvrEn;
   UINT32   OvrVal;
   BOOLEAN  IsCpuPcie;
-  UINT32   LtrCfgLock;
 
   IsCpuPcie = FALSE;
   OvrEn = 0;
   OvrVal = 0;
-  LtrCfgLock = 0;
 
   if (DevNum == SA_PEG0_DEV_NUM || DevNum == SA_PEG3_DEV_NUM) {
 IsCpuPcie = TRUE;
diff --git 
a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c
 
b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c
index faac07c45d..e88abe550f 100644
--- 
a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c
+++ 
b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c
@@ -313,8 +313,6 @@ DmarTableUpdate (
   UINTN   Offset;
   UINTN   StructureLen;
   UINT64  McD0BaseAddress;
-  UINT32  GttMmAdr;
-  UINT64  McD2BaseAddress;
   UINT16  IgdMode;
   UINT16  GttMode;
   UINT32  IgdMemSize;
@@ -381,9 +379,6 @@ DmarTableUpdate (
 GttMemSize = (1 << GttMode) * (1024) * (1024);
   }
 
-  McD2BaseAddress = PCI_SEGMENT_LIB_ADDRESS (SA_SEG_NUM, IGD_BUS_NUM, 
IGD_DEV_NUM, IGD_FUN_NUM, 0);
-  GttMmAdr = (PciSegmentRead32 (McD2BaseAddress + R_SA_IGD_GTTMMADR)) & 
0xFFF0;
-
   DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionBaseAddress   = 
(PciSegmentRead32 (McD0BaseAddress + R_SA_BGSM) & ~(0x01));
   DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionLimitAddress  = 
DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionBaseAddress + IgdMemSize + 
GttMemSize - 1;
   DEBUG ((DEBUG_INFO, "RMRR Base  address IGD %016lX\n", 
DmarTable->RmrrIgd.RmrrHeader.ReservedMemoryRegionBaseAddress));
diff --git 
a/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c
 
b/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c
index 7693e76683..3adc05ce89 100644
--- 
a/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c
+++ 
b/Silicon/Intel/TigerlakeSiliconPkg/Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c
@@ -29,8 +29,6 @@ GetPcieRpNumber (
   OUT UINTN   *RpNumber
   )
 {
-  UINT64  RpBase;
-  RpBase = PCI_SEGMENT_LIB_ADDRESS (SA_SEG_NUM, SA_MC_BUS, RpDev, RpFun, 0);
   GetPchPcieRpNumber (RpDev, RpFun, RpNumber);
 }
 
-- 
2.30.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72131): https://edk2.groups.io/g/devel/message/72131
Mute This Topic: https://groups.io/mt/80867664/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH edk2-platforms v1 0/2] TigerlakeOpenBoardPkg: Fix build error with GCC5

2021-02-23 Thread Takuto Naito
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224

Fix build errors caused by "-Werror=unused-but-set-variable" with GCC5.
These build errors occur only with DEBUG target because
RELEASE_GCC5_X64_CC_FLAGS has "-Wno-unused-but-set-variable",
but DEBUG_GCC5_X64_CC_FLAGS doesn't.

https://github.com/naitaku/edk2-platforms/tree/tigerlake_fix_unused-but-set-variable_v1

Cc: Sai Chaganty 
Cc: Nate DeSimone 
Cc: Heng Luo 

Takuto Naito (2):
  TigerlakeSiliconPkg: Fix build error with GCC5
  TigerlakeOpenBoardPkg: Fix build error with GCC5

 .../Library/BasePlatformHookLib/BasePlatformHookLib.c | 8 
 .../Library/BoardInitLib/PeiTigerlakeURvpInitPreMemLib.c  | 2 ++
 .../LibraryPrivate/PcieClientRpLib/PcieClientRpLib.c  | 2 --
 .../Vtd/LibraryPrivate/DxeVtdInitLib/DxeVtdInitLib.c  | 5 -
 .../Pch/PchSmiDispatcher/Smm/PchSmiHelperClient.c | 2 --
 5 files changed, 2 insertions(+), 17 deletions(-)

-- 
2.30.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72130): https://edk2.groups.io/g/devel/message/72130
Mute This Topic: https://groups.io/mt/80867658/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition and null instance

2021-02-23 Thread Yao, Jiewen
I feel the name is confusing.

The class name is DxeMmUnblockMemoryLib. But actually, this is not related to 
DXE phase.

I believe, it is also applicable to PEI phase, if we have a PEI instance. 
Please correct me if I am wrong.
Also, we can have SMM instance, right?

If that is true, then I prefer to remove Dxe prefix.

From: Wu, Hao A 
Sent: Wednesday, February 24, 2021 9:27 AM
To: Kun Qin ; devel@edk2.groups.io; Yao, Jiewen 
; gaoliming ; Kinney, Michael D 
; Liu, Zhiguang 
Cc: Wang, Jian J ; Dong, Eric ; Ni, 
Ray 
Subject: RE: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Thanks Kun,

For putting the new library in MdePkg, I am not sure whether this is a similar 
case to SmmMemLib.
I looped Jiewen, Liming and Mike to check if they have comments on this.

Best Regards,
Hao Wu

From: Kun Qin mailto:ku...@outlook.com>>
Sent: Wednesday, February 24, 2021 3:30 AM
To: devel@edk2.groups.io; Wu, Hao A 
mailto:hao.a...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>; gaoliming 
mailto:gaolim...@byosoft.com.cn>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Liu, Zhiguang 
mailto:zhiguang@intel.com>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>; Dong, 
Eric mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: RE: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hi Hao,

Thanks for the suggestion. I can move the library to MdePkg similar to 
SmmMemLib and add the change for OVMF.

Liming/Zhiguang,

I am happy to prepare patches to cover the dependency change in ed2-platform in 
a separate patch series. But please let me know if you would like to proceed 
otherwise.

Thanks,
Kun

From: Wu, Hao A
Sent: Monday, February 22, 2021 17:42
To: Kun Qin; 
devel@edk2.groups.io; Yao, 
Jiewen; 
gaoliming; Kinney, Michael 
D; Liu, 
Zhiguang
Cc: Wang, Jian J; Dong, 
Eric; Ni, Ray
Subject: Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hello Kun,

Sorry for the delayed response.

Except for missing the UNI file for the newly added library, I do not have 
other comment for the implementation at this moment.
But I am wondering if this library can be added into the MdePkg as the case for 
MdePkg\Library\SmmMemLib\
I have looped in Jiewen, Liming and Mike for comments.

Also, since:
* New library dependency for VariableSmmRuntimeDxe.inf
* INF file separation and new library dependency in Tcg2Smm
I think the series needs to prepare the changes for platforms under edk2 (OVMF) 
and edk2-platforms repositories that consume the above 2 modules.
I am not exactly sure on how this should be handled within edk2-platforms, so I 
added Liming and Zhiguang here for comments.

Best Regards,
Hao Wu

From: Kun Qin mailto:ku...@outlook.com>>
Sent: Tuesday, February 23, 2021 6:15 AM
To: devel@edk2.groups.io; Wu, Hao A 
mailto:hao.a...@intel.com>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>; Dong, 
Eric mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>
Subject: RE: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added 
definition and null instance

Hi Hao,

The patch series was resent with intended usage in VariableRuntime and Tcg2 
drivers. Could you please provide feedback on them? Any input is appreciated.

Regards,
Kun

From: Kun Qin
Sent: Tuesday, February 9, 2021 17:25
To: devel@edk2.groups.io
Cc: Jian J Wang; Hao A 
Wu; Eric Dong; Ray 
Ni; Jiewen Yao
Subject: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition 
and null instance

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3168

This interface definition provides an abstraction layer for DXE drivers
to request certain memory blocks to be mapped/unblocked for accessibility
inside MM environment.

Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Eric Dong mailto:eric.d...@intel.com>>
Cc: Ray Ni mailto:ray...@intel.com>>
Cc: Jiewen Yao mailto:jiewen@intel.com>>

Signed-off-by: Kun Qin mailto:ku...@outlook.com>>
---

Notes:
v2:
- Resend with practical usage. No change [Hao]

 MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c   | 40 

 MdeModulePkg/Include/Library/DxeMmUnblockMemoryLib.h | 40 

 MdeModulePkg/Library/DxeMmUnblockM

Re: [edk2-devel] [PATCH v2 6/6] SecurityPkg: Tcg2Acpi: Added unblock memory interface for NVS region

2021-02-23 Thread Yao, Jiewen
Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Kun Qin 
> Sent: Wednesday, February 10, 2021 9:25 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 
> Subject: [PATCH v2 6/6] SecurityPkg: Tcg2Acpi: Added unblock memory interface
> for NVS region
> 
> This changes added usage of DxeMmUnblockMemoryLib to explicitly request
> allocated NVS region to be accessible from MM environment. It will bring
> in compatibility with architectures that supports full memory blockage
> inside MM.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
> 
> Signed-off-by: Kun Qin 
> ---
> 
> Notes:
> v2:
> - Newly added in v2.
> 
>  SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c   | 6 ++
>  SecurityPkg/SecurityPkg.dsc   | 1 +
>  SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf | 1 +
>  3 files changed, 8 insertions(+)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> index 7080df81efe7..cc37a8d5b9d9 100644
> --- a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> +++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> @@ -36,6 +36,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  //
>  // Physical Presence Interface Version supported by Platform
> @@ -145,6 +146,11 @@ AssignOpRegion (
>ZeroMem ((VOID *)(UINTN)MemoryAddress, Size);
>OpRegion->RegionOffset = (UINT32) (UINTN) MemoryAddress;
>OpRegion->RegionLen= (UINT8) Size;
> +  // Request to unblock this region from MM core
> +  Status = DxeMmUnblockMemoryRequest (MemoryAddress,
> EFI_SIZE_TO_PAGES (Size));
> +  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
> +ASSERT_EFI_ERROR (Status);
> +  }
>break;
>  }
>}
> diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
> index 37242da93f3d..d937521db388 100644
> --- a/SecurityPkg/SecurityPkg.dsc
> +++ b/SecurityPkg/SecurityPkg.dsc
> @@ -67,6 +67,7 @@ [LibraryClasses]
>
> VariableKeyLib|SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf
>RpmcLib|SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf
> 
> TcgEventLogRecordLib|SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLo
> gRecordLib.inf
> +
> DxeMmUnblockMemoryLib|MdeModulePkg/Library/DxeMmUnblockMemoryLib
> /DxeMmUnblockMemoryLibNull.inf
> 
>  [LibraryClasses.ARM]
>#
> diff --git a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
> b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
> index d8e06881c01d..60455610f9f6 100644
> --- a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
> +++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
> @@ -55,6 +55,7 @@ [LibraryClasses]
>Tpm2CommandLib
>Tcg2PhysicalPresenceLib
>PcdLib
> +  DxeMmUnblockMemoryLib
> 
>  [Guids]
>gEfiTpmDeviceInstanceTpm20DtpmGuid## PRODUCES  
>  ##
> GUID   # TPM device identifier
> --
> 2.30.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72128): https://edk2.groups.io/g/devel/message/72128
Mute This Topic: https://groups.io/mt/80522088/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition and null instance

2021-02-23 Thread Wu, Hao A
Thanks Kun,

For putting the new library in MdePkg, I am not sure whether this is a similar 
case to SmmMemLib.
I looped Jiewen, Liming and Mike to check if they have comments on this.

Best Regards,
Hao Wu

From: Kun Qin 
Sent: Wednesday, February 24, 2021 3:30 AM
To: devel@edk2.groups.io; Wu, Hao A ; Yao, Jiewen 
; gaoliming ; Kinney, Michael D 
; Liu, Zhiguang 
Cc: Wang, Jian J ; Dong, Eric ; Ni, 
Ray 
Subject: RE: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hi Hao,

Thanks for the suggestion. I can move the library to MdePkg similar to 
SmmMemLib and add the change for OVMF.

Liming/Zhiguang,

I am happy to prepare patches to cover the dependency change in ed2-platform in 
a separate patch series. But please let me know if you would like to proceed 
otherwise.

Thanks,
Kun

From: Wu, Hao A
Sent: Monday, February 22, 2021 17:42
To: Kun Qin; 
devel@edk2.groups.io; Yao, 
Jiewen; 
gaoliming; Kinney, Michael 
D; Liu, 
Zhiguang
Cc: Wang, Jian J; Dong, 
Eric; Ni, Ray
Subject: Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hello Kun,

Sorry for the delayed response.

Except for missing the UNI file for the newly added library, I do not have 
other comment for the implementation at this moment.
But I am wondering if this library can be added into the MdePkg as the case for 
MdePkg\Library\SmmMemLib\
I have looped in Jiewen, Liming and Mike for comments.

Also, since:
* New library dependency for VariableSmmRuntimeDxe.inf
* INF file separation and new library dependency in Tcg2Smm
I think the series needs to prepare the changes for platforms under edk2 (OVMF) 
and edk2-platforms repositories that consume the above 2 modules.
I am not exactly sure on how this should be handled within edk2-platforms, so I 
added Liming and Zhiguang here for comments.

Best Regards,
Hao Wu

From: Kun Qin mailto:ku...@outlook.com>>
Sent: Tuesday, February 23, 2021 6:15 AM
To: devel@edk2.groups.io; Wu, Hao A 
mailto:hao.a...@intel.com>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>; Dong, 
Eric mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>
Subject: RE: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added 
definition and null instance

Hi Hao,

The patch series was resent with intended usage in VariableRuntime and Tcg2 
drivers. Could you please provide feedback on them? Any input is appreciated.

Regards,
Kun

From: Kun Qin
Sent: Tuesday, February 9, 2021 17:25
To: devel@edk2.groups.io
Cc: Jian J Wang; Hao A 
Wu; Eric Dong; Ray 
Ni; Jiewen Yao
Subject: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition 
and null instance

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3168

This interface definition provides an abstraction layer for DXE drivers
to request certain memory blocks to be mapped/unblocked for accessibility
inside MM environment.

Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Eric Dong mailto:eric.d...@intel.com>>
Cc: Ray Ni mailto:ray...@intel.com>>
Cc: Jiewen Yao mailto:jiewen@intel.com>>

Signed-off-by: Kun Qin mailto:ku...@outlook.com>>
---

Notes:
v2:
- Resend with practical usage. No change [Hao]

 MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c   | 40 

 MdeModulePkg/Include/Library/DxeMmUnblockMemoryLib.h | 40 

 MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.inf | 29 
++
 MdeModulePkg/MdeModulePkg.dec|  5 
+++
 MdeModulePkg/MdeModulePkg.dsc|  2 +
 5 files changed, 116 insertions(+)

diff --git 
a/MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c 
b/MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c
new file mode 100644
index ..774a7e41cfb0
--- /dev/null
+++ b/MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c
@@ -0,0 +1,40 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an abstraction layer of requesting certain page access 
to be unblocked
+  by MM environment if applicable.
+
+  Copyright (c), Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain

Re: [edk2-devel] [PATCH v2 5/6] SecurityPkg: Tcg2Smm: Added support for Standalone Mm

2021-02-23 Thread Yao, Jiewen
I am not sure if Tcg2MmDependencyLib is the best solution.

It seems NULL lib instance. But I am not sure how it is used. 

Can we have an example in SecurityPkg.dsc?



> -Original Message-
> From: Kun Qin 
> Sent: Wednesday, February 10, 2021 9:25 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 
> Subject: [PATCH v2 5/6] SecurityPkg: Tcg2Smm: Added support for Standalone
> Mm
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3169
> 
> This change added Standalone MM instance of Tcg2. The notify function for
> Standalone MM instance is left empty.
> 
> A designated dependency library was created for DXE drivers to link as an
> anonymous library.
> 
> Lastly, the support of CI build for Tcg2 Standalone MM module is added.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
> 
> Signed-off-by: Kun Qin 
> ---
> 
> Notes:
> v2:
> - Newly added.
> 
>  SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c   | 48
> 
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c  | 71
> ++
>  SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.inf | 39
> ++
>  SecurityPkg/SecurityPkg.ci.yaml |  1 +
>  SecurityPkg/SecurityPkg.dec |  1 +
>  SecurityPkg/SecurityPkg.dsc | 10 +++
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.inf| 77
> 
>  7 files changed, 247 insertions(+)
> 
> diff --git
> a/SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c
> b/SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c
> new file mode 100644
> index ..12b23813dce1
> --- /dev/null
> +++ b/SecurityPkg/Library/Tcg2MmDependencyLib/Tcg2MmDependencyLib.c
> @@ -0,0 +1,48 @@
> +/** @file
> +  Runtime DXE part corresponding to StandaloneMM Tcg2 module.
> +
> +This module installs gTcg2MmSwSmiRegisteredGuid to notify readiness of
> +StandaloneMM Tcg2 module.
> +
> +Copyright (c) 2019 - 2021, Arm Ltd. All rights reserved.
> +Copyright (c) Microsoft Corporation.
> +
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +/**
> +  The constructor function installs gTcg2MmSwSmiRegisteredGuid to notify
> +  readiness of StandaloneMM Tcg2 module.
> +
> +  @param  ImageHandle   The firmware allocated handle for the EFI image.
> +  @param  SystemTable   A pointer to the Management mode System Table.
> +
> +  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +Tcg2MmDependencyLibConstructor (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *SystemTable
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_HANDLEHandle;
> +
> +  Handle = NULL;
> +  Status = gBS->InstallProtocolInterface (
> +  &Handle,
> +  &gTcg2MmSwSmiRegisteredGuid,
> +  EFI_NATIVE_INTERFACE,
> +  NULL
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +  return EFI_SUCCESS;
> +}
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
> new file mode 100644
> index ..9e0095efbc5e
> --- /dev/null
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
> @@ -0,0 +1,71 @@
> +/** @file
> +  TCG2 Standalone MM driver that updates TPM2 items in ACPI table and
> registers
> +  SMI2 callback functions for Tcg2 physical presence, ClearMemory, and
> +  sample for dTPM StartMethod.
> +
> +  Caution: This module requires additional review when modified.
> +  This driver will have external input - variable and ACPINvs data in SMM 
> mode.
> +  This external input must be validated carefully to avoid security issue.
> +
> +  PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted
> input and do some check.
> +
> +Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) Microsoft Corporation.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include "Tcg2Smm.h"
> +#include 
> +
> +/**
> +  Notify the system that the SMM variable driver is ready.
> +**/
> +VOID
> +Tcg2NotifyMmReady (
> +  VOID
> +  )
> +{
> +  // Do nothing
> +}
> +
> +/**
> +  This function is an abstraction layer for implementation specific Mm buffer
> validation routine.
> +
> +  @param Buffer  The buffer start address to be checked.
> +  @param Length  The buffer length to be checked.
> +
> +  @retval TRUE  This buffer is valid per processor architecture and not 
> overlap
> with SMRAM.
> +  @retval FALSE This buffer is not valid per processor architecture or 
> overlap
> with SMRAM.
> +**/
> +BOOLEAN
> +IsBufferOutsideMmValid (
> +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> +  IN UINT64Length
> +  )
> +{
> +  return MmIsBufferOutsideMmValid (Buffer, Le

Re: [edk2-devel] [PATCH v2 4/6] SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2 modules

2021-02-23 Thread Yao, Jiewen
Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Kun Qin 
> Sent: Wednesday, February 10, 2021 9:25 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 
> Subject: [PATCH v2 4/6] SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2
> modules
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3169
> 
> This change separated the original Tcg2Smm module into 2 drivers: the
> SMM driver that registers callback for physical presence and memory
> clear; the Tcg2Acpi driver that patches and publishes ACPI table for
> runtime use.
> 
> Tcg2Smm introduced an SMI root handler to allow Tcg2Acpi to communicate
> the NVS region used by Tpm.asl and exchange the registered SwSmiValue.
> 
> Lastly, Tcg2Smm driver will publish gTcg2MmSwSmiRegisteredGuid at the end
> of entrypoint to ensure Tcg2Acpi to load after Tcg2Smm is ready to
> communicate.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
> 
> Signed-off-by: Kun Qin 
> ---
> 
> Notes:
> v2:
> - Newly added in v2.
> 
> v2:
> - Newly added.
> 
>  SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c} | 350 -
> ---
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c  | 850 
> 
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c|  82 ++
>  SecurityPkg/Include/Guid/TpmNvsMm.h|  68 ++
>  SecurityPkg/SecurityPkg.dec|   7 +
>  SecurityPkg/SecurityPkg.dsc|   1 +
>  SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf} |  32 +-
>  SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl  |   0
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h  | 119 +--
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf|  25 +-
>  10 files changed, 542 insertions(+), 992 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> similarity index 72%
> copy from SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> copy to SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> index 08105c3692ba..7080df81efe7 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> +++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
> @@ -1,20 +1,74 @@
>  /** @file
> -  It updates TPM2 items in ACPI table and registers SMI2 callback
> -  functions for Tcg2 physical presence, ClearMemory, and sample
> -  for dTPM StartMethod.
> +  This driver implements TPM 2.0 definition block in ACPI table and
> +  populates registered SMI callback functions for Tcg2 physical presence
> +  and MemoryClear to handle the requests for ACPI method.
> 
>Caution: This module requires additional review when modified.
>This driver will have external input - variable and ACPINvs data in SMM 
> mode.
>This external input must be validated carefully to avoid security issue.
> 
> -  PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted
> input and do some check.
> -
>  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) Microsoft Corporation.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
> -#include "Tcg2Smm.h"
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +//
> +// Physical Presence Interface Version supported by Platform
> +//
> +#define PHYSICAL_PRESENCE_VERSION_TAG  "$PV"
> +#define PHYSICAL_PRESENCE_VERSION_SIZE 4
> +
> +//
> +// PNP _HID for TPM2 device
> +//
> +#define TPM_HID_TAG""
> +#define TPM_HID_PNP_SIZE   8
> +#define TPM_HID_ACPI_SIZE  9
> +
> +#define TPM_PRS_RESL   "RESL"
> +#define TPM_PRS_RESS   "RESS"
> +#define TPM_PRS_RES_NAME_SIZE  4
> +//
> +// Minimum PRS resource template size
> +//  1 bytefor  BufferOp
> +//  1 bytefor  PkgLength
> +//  2 bytes   for  BufferSize
> +//  12 bytes  for  Memory32Fixed descriptor
> +//  5 bytes   for  Interrupt descriptor
> +//  2 bytes   for  END Tag
> +//
> +#define TPM_POS_RES_TEMPLATE_MIN_SIZE  (1 + 1 + 
> 2 + 12 +
> 5 + 2)
> +
> +//
> +// Max Interrupt buffer size for PRS interrupt resource
> +// Now support 15 interrupts in maxmum
> +//
> +#define MAX_PRS_INT_BUF_SIZE   (15*4)
> 
>  #pragma pack(1)
> 
> @@ -49,142 +103,8 @@ EFI_TPM2_ACPI_TABLE_V4  mTpm2AcpiTemplate = {
>EFI_TPM2_ACPI_TABLE_START_METHOD_TIS, // StartMethod
>  };
> 
> -EFI_SMM_VARIABLE_PROTOCOL  *mSmmVariable;
>  TCG_NVS 

Re: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Error handling of Ufs Pass Thru driver

2021-02-23 Thread Wu, Hao A
Hello Liming,

I have a patch that would like to confirm with you that whether it can be 
merged into the upcoming edk2-stable202102 tag.

This is a feature request: https://bugzilla.tianocore.org/show_bug.cgi?id=3217
In the BZ tracker, there are 3 improvements mentioned for UfsPassThruDxe.
According to Purna, he would like to have 1 of the improvements (improvement #3 
in BZ-3217) be merged and catch the stable tag.
I have given the 'R-b' tag for improvement #3 already 
(https://edk2.groups.io/g/devel/message/72121)

My thought is that we can break BZ-3217 into multiple feature requests:
1. BZ-3217: Updated its title and description to only cover improvement #3
2. File new BZ feature requests to cover improvement #1 & #2

What is your suggestion for this case? Thanks in advance.

Best Regards,
Hao Wu

> -Original Message-
> From: Bandaru, Purna Chandra Rao 
> Sent: Tuesday, February 23, 2021 10:36 PM
> To: Wu, Hao A ; devel@edk2.groups.io
> Cc: Albecki, Mateusz ; Ni, Ray
> 
> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> Improve Error handling of Ufs Pass Thru driver
> 
> Hi Wu, Hao A
> 
> I am trying to focus on merging patch#1 for now to unblock boot issues.
> March 6th might be too late, May I request you to expedite any other
> alternatives like exceptions/overrides?
> For the remaining two patches I will get back to you with the plan after
> discussing with WSIV and MVE teams on the protocol analyzer tools etc.
> 
> Thanks
> ~Purna
> 
> -Original Message-
> From: Wu, Hao A 
> Sent: Tuesday, February 23, 2021 6:46 AM
> To: Bandaru, Purna Chandra Rao ;
> devel@edk2.groups.io
> Cc: Albecki, Mateusz ; Ni, Ray
> 
> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> Improve Error handling of Ufs Pass Thru driver
> 
> > -Original Message-
> > From: Bandaru, Purna Chandra Rao
> 
> > Sent: Tuesday, February 23, 2021 1:11 AM
> > To: Wu, Hao A ; devel@edk2.groups.io
> > Cc: Albecki, Mateusz ; Ni, Ray
> > 
> > Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> > Improve Error handling of Ufs Pass Thru driver
> >
> > Thank you Hai Bu for the response.
> >
> > I have broken this into three separate patches. There were no specific
> > recommendation in the speciation for seen multiple issues on all the
> > UFS platforms like LKF, ADP-P and EHK.
> 
> 
> Hello,
> 
> After quickly going through the new series sent, I do not see my previous
> inline comments and questions get addressed.
> Could you please help to provide your feedbacks and update the patches?
> 
> 
> > And these changes worked on all the three with various UFS cards.
> > Can you please review and help to get this changes at the earliest in
> > master as well as Downstream/master.
> 
> 
> Sorry, since there is an upcoming stable tag approaching, at this moment, I
> prefer to hold this feature after the stable tag (March 6th).
> 
> Best Regards,
> Hao Wu
> 
> 
> >
> > Thanks
> > ~Purna
> >
> > -Original Message-
> > From: Wu, Hao A 
> > Sent: Monday, February 22, 2021 2:10 PM
> > To: devel@edk2.groups.io; Wu, Hao A ; Bandaru,
> > Purna Chandra Rao 
> > Cc: Albecki, Mateusz ; Ni, Ray
> > 
> > Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> > Improve Error handling of Ufs Pass Thru driver
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Wu,
> > Hao
> > > A
> > > Sent: Monday, February 22, 2021 4:38 PM
> > > To: Bandaru, Purna Chandra Rao
> > > ;
> > > devel@edk2.groups.io
> > > Cc: Albecki, Mateusz ; Ni, Ray
> > > 
> > > Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> > > Improve Error handling of Ufs Pass Thru driver
> > >
> > > > -Original Message-
> > > > From: Bandaru, Purna Chandra Rao
> > > 
> > > > Sent: Wednesday, February 17, 2021 5:02 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Bandaru, Purna Chandra Rao
> > > > ;
> > > > Albecki, Mateusz ; Ni, Ray
> > > > ; Wu, Hao A 
> > > > Subject: [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Error
> > handling
> > > > of Ufs Pass Thru driver
> > > >
> > > > From: Bandaru 
> > > >
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3217
> > > >
> > > > Following is the brief description of the changes
> > > >  1) There are cards that can take upto 600ms for Init and hence increase
> > > > the time out for fDeviceInit polling loop.
> > > >  2) Add UFS host conctroller reset in the last retry of Link start up.
> > > >  3) Retry sending NOP OUT command upto 10 times
> > >
> > >
> > > Hello Bandaru,
> > >
> > > Could you help to break this patch into a 3-patch series in V2?
> > > With each patch handling just one of the above 3 improvements
> > mentioned.
> > >
> > > For improvement 2) above, I do not see such UFS host controller
> > > re-enabling process being mentioned in UFSHCI 3.0 spec section 7.1.1.
> > > Is this process being documented somewhere else in the spec or
> > > suggested by device vender?
> >
> >
> > Sorry for missing one comment.
>

Re: [edk2-devel] [PATCH v2 3/6] SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst

2021-02-23 Thread Yao, Jiewen
Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Kun Qin 
> Sent: Wednesday, February 10, 2021 9:25 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 
> Subject: [PATCH v2 3/6] SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst
> 
> This change replaced gSmst with gMmst to support broader compatibility
> under MM environment for Tcg2Smm driver.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
> 
> Signed-off-by: Kun Qin 
> ---
> 
> Notes:
> v2:
> - Newly added in v2.
> 
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c   | 4 ++--
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h   | 2 +-
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> index 91aebb62b8bf..08105c3692ba 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> @@ -870,7 +870,7 @@ InitializeTcgSmm (
>//
>// Get the Sw dispatch protocol and register SMI callback functions.
>//
> -  Status = gSmst->SmmLocateProtocol (&gEfiSmmSwDispatch2ProtocolGuid,
> NULL, (VOID**)&SwDispatch);
> +  Status = gMmst->MmLocateProtocol (&gEfiSmmSwDispatch2ProtocolGuid,
> NULL, (VOID**)&SwDispatch);
>ASSERT_EFI_ERROR (Status);
>SwContext.SwSmiInputValue = (UINTN) -1;
>Status = SwDispatch->Register (SwDispatch, PhysicalPresenceCallback,
> &SwContext, &SwHandle);
> @@ -891,7 +891,7 @@ InitializeTcgSmm (
>//
>// Locate SmmVariableProtocol.
>//
> -  Status = gSmst->SmmLocateProtocol (&gEfiSmmVariableProtocolGuid, NULL,
> (VOID**)&mSmmVariable);
> +  Status = gMmst->MmLocateProtocol (&gEfiSmmVariableProtocolGuid, NULL,
> (VOID**)&mSmmVariable);
>ASSERT_EFI_ERROR (Status);
> 
>//
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
> index fd19e7dc0553..d7328c8f2ac9 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
> @@ -24,7 +24,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
> index 2ebf2e05f2ea..872ed27cbe71 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
> @@ -50,7 +50,7 @@ [LibraryClasses]
>BaseLib
>BaseMemoryLib
>UefiDriverEntryPoint
> -  SmmServicesTableLib
> +  MmServicesTableLib
>UefiBootServicesTableLib
>DebugLib
>DxeServicesLib
> --
> 2.30.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72123): https://edk2.groups.io/g/devel/message/72123
Mute This Topic: https://groups.io/mt/80522085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2 0/2] TigerlakeOpenBoard: Fix build errors with GCC5

2021-02-23 Thread Heng Luo
Hi Takuto Naito,
I think you can add comments in the same BZ ticket and then use it.

Thanks,
Heng

From: devel@edk2.groups.io  On Behalf Of Takuto Naito
Sent: Wednesday, February 24, 2021 1:02 AM
To: Desimone, Nathaniel L 
Cc: Chaganty, Rangasai V ; Luo, Heng 
; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v2 0/2] TigerlakeOpenBoard: Fix build errors 
with GCC5

Hi Nate and Heng,

The RELEASE build now succeeds, but I noticed that DEBUG build still fails.
I'm trying to fix it. Do you need me to submit another BZ ticket or use the 
same ticket?

Best regards,
Takuto Naito

On Tue, Feb 23, 2021 at 7:27 AM Desimone, Nathaniel L 
mailto:nathaniel.l.desim...@intel.com>> wrote:
The series has been pushed as 12ef75d~.. 9fb5174

Thanks,
Nate

> -Original Message-
> From: Takuto Naito mailto:nait...@gmail.com>>
> Sent: Sunday, February 21, 2021 7:10 AM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V 
> mailto:rangasai.v.chaga...@intel.com>>; 
> Desimone,
> Nathaniel L 
> mailto:nathaniel.l.desim...@intel.com>>; Luo, 
> Heng
> mailto:heng@intel.com>>
> Subject: [PATCH v2 0/2] TigerlakeOpenBoard: Fix build errors with GCC5
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224
> TigerlakeOpenBoard: Fix build errors with GCC5
>
> v2:
> - Split the v1 patch into 2 patches.
>   One is for Platform/Intel/TigerlakeOpenBoardPkg,
>   another one is for edk2-platforms\Silicon\Intel\TigerlakeSiliconPkg.
>
> https://github.com/naitaku/edk2-
> platforms/tree/tigerlake_fix_build_error_v2
>
> Cc: Sai Chaganty 
> mailto:rangasai.v.chaga...@intel.com>>
> Cc: Nate DeSimone 
> mailto:nathaniel.l.desim...@intel.com>>
> Cc: Heng Luo mailto:heng@intel.com>>
>
> Takuto Naito (2):
>   TigerlakeOpenBoardPkg: Fix build errors with GCC5
>   TigerlakeSiliconPkg/IpBlock: Fix build errors with GCC5
>
>  .../PeiFspPolicyInitLib.inf   |   2 +-
>  .../BasePlatformHookLib/BasePlatformHookLib.c | 188 --
>  .../DxeSiliconPolicyUpdateLate.c  |   2 +-
>  .../DxePchPcieRpPolicyLib.c   |   2 +-
>  4 files changed, 3 insertions(+), 191 deletions(-)
>
> --
> 2.30.1
--
内藤 卓人
Takuto Naito



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72122): https://edk2.groups.io/g/devel/message/72122
Mute This Topic: https://groups.io/mt/80801576/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Device initialization polling Loop

2021-02-23 Thread Wu, Hao A
> -Original Message-
> From: Bandaru, Purna Chandra Rao 
> Sent: Tuesday, February 23, 2021 10:32 PM
> To: devel@edk2.groups.io
> Cc: Bandaru, Purna Chandra Rao ;
> Albecki, Mateusz ; Ni, Ray ;
> Wu, Hao A 
> Subject: [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Device
> initialization polling Loop
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3217
> 
> Current Ufs Pass thru driver polls for 5us and return success even when the
> timeout occurs.
> There are cards that can take upto 600ms for Init and hence increased the
> time out for fDeviceInit polling loop.
> 
> Signed-off-by: Bandaru 
> Cc: Mateusz Albecki 
> Cc: Ray Ni 
> Cc: Hao A Wu 
> 
> Change-Id: I6cb063b43bdf37790db8e60c3919153cd2f3c086
> ---
>  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 17
> +
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h |  3 ++-
>  2 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> index 9768c2e6fb..92ff958f16 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2021, Intel Corporation. All rights
> + reserved.
>Copyright (c) Microsoft Corporation.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> @@ -749,7 +749,7 @@ UfsFinishDeviceInitialization (  {
>EFI_STATUS  Status;
>UINT8  DeviceInitStatus;
> -  UINT8  Timeout;
> +  UINT32 Timeout;
> 
>DeviceInitStatus = 0xFF;
> 
> @@ -761,7 +761,10 @@ UfsFinishDeviceInitialization (
>  return Status;
>}
> 
> -  Timeout = 5;
> +  //
> +  // There are cards that can take upto 600ms to clear fDeviceInit flag.
> +  //
> +  Timeout = UFS_INIT_COMPLETION_TIMEOUT;
>do {
>  Status = UfsReadFlag (Private, UfsFlagDevInit, &DeviceInitStatus);
>  if (EFI_ERROR (Status)) {
> @@ -771,7 +774,13 @@ UfsFinishDeviceInitialization (
>  Timeout--;
>} while (DeviceInitStatus != 0 && Timeout != 0);
> 
> -  return EFI_SUCCESS;
> +  if (Timeout == 0) {
> +DEBUG ((DEBUG_ERROR, "UfsFinishDeviceInitialization
> DeviceInitStatus=%x EFI_TIMEOUT \n", DeviceInitStatus));
> +return EFI_TIMEOUT;
> +  } else {
> +DEBUG ((DEBUG_INFO, "UfsFinishDeviceInitialization Timeout left=%x
> EFI_SUCCESS \n", Timeout));
> +return EFI_SUCCESS;
> +  }
>  }
> 
>  /**
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> index ef33250c89..275351cf8e 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2021, Intel Corporation. All rights
> + reserved.
>Copyright (c) Microsoft Corporation.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> @@ -40,6 +40,7 @@
>  //
>  #define UFS_MAX_LUNS12
>  #define UFS_WLUN_PREFIX 0xC1
> +#define UFS_INIT_COMPLETION_TIMEOUT 60


I will help to remove the tailing space in the above line before pushing the 
patch.
(Not sure if the tailing space is generated when I extract the patch from my 
mailing agent.)

Anyway,
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


> 
>  typedef struct {
>UINT8Lun[UFS_MAX_LUNS];
> --
> 2.16.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72121): https://edk2.groups.io/g/devel/message/72121
Mute This Topic: https://groups.io/mt/80864767/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Error handling of Ufs Pass Thru driver

2021-02-23 Thread Bandaru, Purna Chandra Rao
Hi Wu, Hao A

I am trying to focus on merging patch#1 for now to unblock boot issues. March 
6th might be too late, May I request you to expedite any other alternatives 
like exceptions/overrides?
For the remaining two patches I will get back to you with the plan after 
discussing with WSIV and MVE teams on the protocol analyzer tools etc. 

Thanks 
~Purna

-Original Message-
From: Wu, Hao A  
Sent: Tuesday, February 23, 2021 6:46 AM
To: Bandaru, Purna Chandra Rao ; 
devel@edk2.groups.io
Cc: Albecki, Mateusz ; Ni, Ray 
Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Error 
handling of Ufs Pass Thru driver

> -Original Message-
> From: Bandaru, Purna Chandra Rao 
> Sent: Tuesday, February 23, 2021 1:11 AM
> To: Wu, Hao A ; devel@edk2.groups.io
> Cc: Albecki, Mateusz ; Ni, Ray 
> 
> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> Improve Error handling of Ufs Pass Thru driver
> 
> Thank you Hai Bu for the response.
> 
> I have broken this into three separate patches. There were no specific 
> recommendation in the speciation for seen multiple issues on all the 
> UFS platforms like LKF, ADP-P and EHK.


Hello,

After quickly going through the new series sent, I do not see my previous 
inline comments and questions get addressed.
Could you please help to provide your feedbacks and update the patches?


> And these changes worked on all the three with various UFS cards.
> Can you please review and help to get this changes at the earliest in 
> master as well as Downstream/master.


Sorry, since there is an upcoming stable tag approaching, at this moment, I 
prefer to hold this feature after the stable tag (March 6th).

Best Regards,
Hao Wu


> 
> Thanks
> ~Purna
> 
> -Original Message-
> From: Wu, Hao A 
> Sent: Monday, February 22, 2021 2:10 PM
> To: devel@edk2.groups.io; Wu, Hao A ; Bandaru, 
> Purna Chandra Rao 
> Cc: Albecki, Mateusz ; Ni, Ray 
> 
> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> Improve Error handling of Ufs Pass Thru driver
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Wu,
> Hao
> > A
> > Sent: Monday, February 22, 2021 4:38 PM
> > To: Bandaru, Purna Chandra Rao 
> > ;
> > devel@edk2.groups.io
> > Cc: Albecki, Mateusz ; Ni, Ray 
> > 
> > Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe:
> > Improve Error handling of Ufs Pass Thru driver
> >
> > > -Original Message-
> > > From: Bandaru, Purna Chandra Rao
> > 
> > > Sent: Wednesday, February 17, 2021 5:02 PM
> > > To: devel@edk2.groups.io
> > > Cc: Bandaru, Purna Chandra Rao
> > > ;
> > > Albecki, Mateusz ; Ni, Ray 
> > > ; Wu, Hao A 
> > > Subject: [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Error
> handling
> > > of Ufs Pass Thru driver
> > >
> > > From: Bandaru 
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=3217
> > >
> > > Following is the brief description of the changes
> > >  1) There are cards that can take upto 600ms for Init and hence increase
> > > the time out for fDeviceInit polling loop.
> > >  2) Add UFS host conctroller reset in the last retry of Link start up.
> > >  3) Retry sending NOP OUT command upto 10 times
> >
> >
> > Hello Bandaru,
> >
> > Could you help to break this patch into a 3-patch series in V2?
> > With each patch handling just one of the above 3 improvements
> mentioned.
> >
> > For improvement 2) above, I do not see such UFS host controller 
> > re-enabling process being mentioned in UFSHCI 3.0 spec section 7.1.1.
> > Is this process being documented somewhere else in the spec or 
> > suggested by device vender?
> 
> 
> Sorry for missing one comment.
> Could you help to add the information on what kind of tests have been 
> performed for the code changes?
> 
> Thanks in advance.
> 
> Best Regards,
> Hao Wu
> 
> 
> >
> > More inline comments below:
> >
> >
> > >
> > > Signed-off-by: Bandaru 
> > > Cc: Mateusz Albecki 
> > > Cc: Ray Ni 
> > > Cc: Hao A Wu 
> > >
> > > Change-Id: I6c0dbc1c147487e51f0ed5f2425957ae089b0160
> > > ---
> > >  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c| 26
> > > +-
> > >  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c | 18
> > > --
> > >  2 files changed, 33 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> > > b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> > > index 9768c2e6fb..89048745be 100644
> > > --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> > > +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> > > @@ -1,6 +1,6 @@
> > >  /** @file
> > >
> > > -  Copyright (c) 2014 - 2019, Intel Corporation. All rights 
> > > reserved.
> > > +  Copyright (c) 2014 - 2021, Intel Corporation. All rights 
> > > + reserved.
> > >Copyright (c) Microsoft Corporation.
> > >SPDX-License-Identifier: BSD-2-Clause-Patent
> > >
> > > @@ -749,7 +749,7 @@ UfsFinishDeviceInitialization (  {
> > >EFI_STATUS 

[edk2-devel] [PATCH] MdeModulePkg/UfsPassThruDxe: Improve Device initialization polling Loop

2021-02-23 Thread Purna Chandra Rao Bandaru
https://bugzilla.tianocore.org/show_bug.cgi?id=3217

Current Ufs Pass thru driver polls for 5us and return success even when
the timeout occurs.
There are cards that can take upto 600ms for Init and hence increased
the time out for fDeviceInit polling loop.

Signed-off-by: Bandaru 
Cc: Mateusz Albecki 
Cc: Ray Ni 
Cc: Hao A Wu 

Change-Id: I6cb063b43bdf37790db8e60c3919153cd2f3c086
---
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 17 +
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h |  3 ++-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c 
b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
index 9768c2e6fb..92ff958f16 100644
--- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
+++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.
   Copyright (c) Microsoft Corporation.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -749,7 +749,7 @@ UfsFinishDeviceInitialization (
 {
   EFI_STATUS  Status;
   UINT8  DeviceInitStatus;
-  UINT8  Timeout;
+  UINT32 Timeout;
 
   DeviceInitStatus = 0xFF;
 
@@ -761,7 +761,10 @@ UfsFinishDeviceInitialization (
 return Status;
   }
 
-  Timeout = 5;
+  //
+  // There are cards that can take upto 600ms to clear fDeviceInit flag.
+  //
+  Timeout = UFS_INIT_COMPLETION_TIMEOUT;
   do {
 Status = UfsReadFlag (Private, UfsFlagDevInit, &DeviceInitStatus);
 if (EFI_ERROR (Status)) {
@@ -771,7 +774,13 @@ UfsFinishDeviceInitialization (
 Timeout--;
   } while (DeviceInitStatus != 0 && Timeout != 0);
 
-  return EFI_SUCCESS;
+  if (Timeout == 0) {
+DEBUG ((DEBUG_ERROR, "UfsFinishDeviceInitialization DeviceInitStatus=%x 
EFI_TIMEOUT \n", DeviceInitStatus));
+return EFI_TIMEOUT;
+  } else {
+DEBUG ((DEBUG_INFO, "UfsFinishDeviceInitialization Timeout left=%x 
EFI_SUCCESS \n", Timeout));
+return EFI_SUCCESS;
+  }
 }
 
 /**
diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h 
b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
index ef33250c89..275351cf8e 100644
--- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
+++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.
   Copyright (c) Microsoft Corporation.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -40,6 +40,7 @@
 //
 #define UFS_MAX_LUNS12
 #define UFS_WLUN_PREFIX 0xC1
+#define UFS_INIT_COMPLETION_TIMEOUT 60 
 
 typedef struct {
   UINT8Lun[UFS_MAX_LUNS];
-- 
2.16.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72119): https://edk2.groups.io/g/devel/message/72119
Mute This Topic: https://groups.io/mt/80864767/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v1 1/2] ArmVirtPkg/PlatformCI: Add EDKII CI support for Kvmtool

2021-02-23 Thread Sean

Sami,

Do you have these in a PR or somewhere online that is already merged? 
Obviously i can do that but usually developers already have that (either 
edk2 PR for ci testing or on their fork).


one comment below.

Thanks
Sean


On 1/22/2021 9:19 AM, Sami Mujawar wrote:

Kvmtool is a virtual machine manager that can be used to launch
guest partitions. ArmVirtPkg already has UEFI (virtual/guest)
firmware support for Kvmtool guest.

Therefore, update the Platform CI script to add support for
building the Kvmtool firmware.

Signed-off-by: Sami Mujawar 
---
  ArmVirtPkg/PlatformCI/PlatformBuild.py | 132 +++-
  ArmVirtPkg/PlatformCI/ReadMe.md|  21 ++--
  2 files changed, 88 insertions(+), 65 deletions(-)

diff --git a/ArmVirtPkg/PlatformCI/PlatformBuild.py 
b/ArmVirtPkg/PlatformCI/PlatformBuild.py
index 
dff653e919eb42391fc56ec44b4043a75f79d162..473f7d58d15c3e26ef5a25e210cb679679b28131
 100644
--- a/ArmVirtPkg/PlatformCI/PlatformBuild.py
+++ b/ArmVirtPkg/PlatformCI/PlatformBuild.py
@@ -2,6 +2,7 @@
  # Script to Build ArmVirtPkg UEFI firmware
  #
  # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2021, Arm Limited. All rights reserved.
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  ##
  import os
@@ -139,7 +140,8 @@ class SettingsManager(UpdateSettingsManager, 
SetupSettingsManager, PrEvalSetting
  
  The tuple should be (, )

  '''


This doesn't look right.  When returning the dsc to use it should only 
return 1 dsc file.  The second parameter of the tuple is for key=value 
pairs to process the DSC file.




-return (os.path.join("ArmVirtPkg", "ArmVirtQemu.dsc"), {})
+return (os.path.join("ArmVirtPkg", "ArmVirtQemu.dsc"),
+os.path.join("ArmVirtPkg", "ArmVirtKvmTool.dsc"), {})
  
  
  # ### #

@@ -150,11 +152,15 @@ class SettingsManager(UpdateSettingsManager, 
SetupSettingsManager, PrEvalSetting
  class PlatformBuilder(UefiBuilder, BuildSettingsManager):
  def __init__(self):
  UefiBuilder.__init__(self)
+self.PlatformList = [os.path.join("ArmVirtPkg", "ArmVirtQemu.dsc"),
+os.path.join("ArmVirtPkg", "ArmVirtKvmTool.dsc")]
  
  def AddCommandLineOptions(self, parserObj):

  ''' Add command line options to the argparser '''
  parserObj.add_argument('-a', "--arch", dest="build_arch", type=str, 
default="AARCH64",
 help="Optional - Architecture to build.  Default = 
AARCH64")
+parserObj.add_argument('-d', "--dsc", dest="active_platform", 
type=str, default=self.PlatformList[0],
+   help="Optional - Platform to build.  Default = 
" + self.PlatformList[0])
  
  def RetrieveCommandLineOptions(self, args):

  '''  Retrieve command line options from the argparser '''
@@ -162,8 +168,12 @@ class PlatformBuilder(UefiBuilder, BuildSettingsManager):
  shell_environment.GetBuildVars().SetValue(
  "TARGET_ARCH", args.build_arch.upper(), "From CmdLine")
  
-shell_environment.GetBuildVars().SetValue(

-"ACTIVE_PLATFORM", "ArmVirtPkg/ArmVirtQemu.dsc", "From CmdLine")
+if (args.active_platform == self.PlatformList[1]):
+shell_environment.GetBuildVars().SetValue(
+"ACTIVE_PLATFORM", self.PlatformList[1], "From CmdLine")
+else:
+shell_environment.GetBuildVars().SetValue(
+"ACTIVE_PLATFORM", self.PlatformList[0], "From CmdLine")
  
  def GetWorkspaceRoot(self):

  ''' get WorkspacePath '''
@@ -207,9 +217,12 @@ class PlatformBuilder(UefiBuilder, BuildSettingsManager):
  
  def SetPlatformEnv(self):

  logging.debug("PlatformBuilder SetPlatformEnv")
-self.env.SetValue("PRODUCT_NAME", "ArmVirtQemu", "Platform Hardcoded")
  self.env.SetValue("MAKE_STARTUP_NSH", "FALSE", "Default to false")
  self.env.SetValue("QEMU_HEADLESS", "FALSE", "Default to false")
+if (self.env.GetValue("ACTIVE_PLATFORM") == self.PlatformList[1]):
+self.env.SetValue("PRODUCT_NAME", "ArmVirtKvmtool", "Platform 
Hardcoded")
+else:
+self.env.SetValue("PRODUCT_NAME", "ArmVirtQemu", "Platform 
Hardcoded")
  return 0
  
  def PlatformPreBuild(self):

@@ -219,58 +232,61 @@ class PlatformBuilder(UefiBuilder, BuildSettingsManager):
  return 0
  
  def FlashRomImage(self):

-VirtualDrive = os.path.join(self.env.GetValue(
-"BUILD_OUTPUT_BASE"), "VirtualDrive")
-os.makedirs(VirtualDrive, exist_ok=True)
-OutputPath_FV = os.path.join(
-self.env.GetValue("BUILD_OUTPUT_BASE"), "FV")
-Built_FV = os.path.join(OutputPath_FV, "QEMU_EFI.fd")
-
-# pad fd to 64mb
-with open(Built_FV, "ab") as fvfile:
-fvfile.seek(0, os.SEEK_END)
-additional = b'\0' * ((64 * 1024

Re: [edk2-devel] [PATCH v8 10/10] OvmfPkg/SmmControl2Dxe: negotiate CPU hot-unplug

2021-02-23 Thread Laszlo Ersek
On 02/22/21 08:19, Ankur Arora wrote:
> Advertise OVMF support for CPU hot-unplug and negotiate it
> if QEMU requests the feature.
> 
> Cc: Laszlo Ersek 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Igor Mammedov 
> Cc: Boris Ostrovsky 
> Cc: Aaron Young 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
> Signed-off-by: Ankur Arora 
> ---
> 
> Notes:
> Addresses the following review comments:
> (1,3) s/hot unplug/hot-unplug/
> (2) Get rid of the reference to the made up ICH9_APM_CNT_CPU_HOT_UNPLUG
> (4,6) Remove the artificial tie in between
>  ICH9_LPC_SMI_F_CPU_HOTPLUG, ICH9_LPC_SMI_F_CPU_HOT_UNPLUG.
> (5) Fully spell out "SMI on CPU hot-unplug".
> (7) Emit separate messages on negotiation (or not) of
>  ICH9_LPC_SMI_F_CPU_HOT_UNPLUG.
> 
>  OvmfPkg/SmmControl2Dxe/SmiFeatures.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c 
> b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
> index c9d875543205..b1d59a559dae 100644
> --- a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
> +++ b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
> @@ -29,6 +29,12 @@
>  //
>  #define ICH9_LPC_SMI_F_CPU_HOTPLUG BIT1
>  
> +// The following bit value stands for "enable CPU hot-unplug, and inject an 
> SMI
> +// with control value ICH9_APM_CNT_CPU_HOTPLUG upon hot-unplug", in the
> +// "etc/smi/supported-features" and "etc/smi/requested-features" fw_cfg 
> files.
> +//
> +#define ICH9_LPC_SMI_F_CPU_HOT_UNPLUG BIT2
> +

(1) The comment formatting is inconsistent with the rest. The line right
after the (extant) "ICH9_LPC_SMI_F_CPU_HOTPLUG" macro definition should
be "//", and not an empty line.

In fact, this new hunk should not introduce any empty line.


>  //
>  // Provides a scratch buffer (allocated in EfiReservedMemoryType type memory)
>  // for the S3 boot script fragment to write to and read from.
> @@ -112,7 +118,8 @@ NegotiateSmiFeatures (
>QemuFwCfgReadBytes (sizeof mSmiFeatures, &mSmiFeatures);
>  
>//
> -  // We want broadcast SMI, SMI on CPU hotplug, and nothing else.
> +  // We want broadcast SMI, SMI on CPU hotplug, SMI on CPU hot-unplug
> +  // and nothing else.
>//
>RequestedFeaturesMask = ICH9_LPC_SMI_F_BROADCAST;
>if (!MemEncryptSevIsEnabled ()) {
> @@ -120,8 +127,10 @@ NegotiateSmiFeatures (
>  // For now, we only support hotplug with SEV disabled.
>  //
>  RequestedFeaturesMask |= ICH9_LPC_SMI_F_CPU_HOTPLUG;
> +RequestedFeaturesMask |= ICH9_LPC_SMI_F_CPU_HOT_UNPLUG;
>}
>mSmiFeatures &= RequestedFeaturesMask;
> +

(2) Spurious empty line addition (it's likely left over from removing
the earlier attempt to "be smarter than QEMU").

The rest seems fine.

Thanks!
Laszlo


>QemuFwCfgSelectItem (mRequestedFeaturesItem);
>QemuFwCfgWriteBytes (sizeof mSmiFeatures, &mSmiFeatures);
>  
> @@ -166,6 +175,13 @@ NegotiateSmiFeatures (
>__FUNCTION__));
>}
>  
> +  if ((mSmiFeatures & ICH9_LPC_SMI_F_CPU_HOT_UNPLUG) == 0) {
> +DEBUG ((DEBUG_INFO, "%a: CPU hot-unplug not negotiated\n", 
> __FUNCTION__));
> +  } else {
> +DEBUG ((DEBUG_INFO, "%a: CPU hot-unplug with SMI negotiated\n",
> +  __FUNCTION__));
> +  }
> +
>//
>// Negotiation successful (although we may not have gotten the optimal
>// feature set).
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72117): https://edk2.groups.io/g/devel/message/72117
Mute This Topic: https://groups.io/mt/80819865/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v8 09/10] OvmfPkg/CpuHotplugSmm: do actual CPU hot-eject

2021-02-23 Thread Laszlo Ersek
On 02/22/21 08:19, Ankur Arora wrote:
> Add logic in EjectCpu() to do the actual the CPU ejection.
> 
> On the BSP, ejection happens by first selecting the CPU via
> its QemuSelector and then sending the QEMU "eject" command.
> QEMU in-turn signals the remote VCPU thread which context-switches
> the CPU out of the SMI handler.
> 
> Meanwhile the CPU being ejected, waits around in its holding
> area until it is context-switched out. Note that it is possible
> that a slow CPU gets ejected before it reaches the wait loop.
> However, this would never happen before it has executed the
> "AllCpusInSync" loop in SmiRendezvous().
> It can mean that an ejected CPU does not execute code after
> that point but given that the CPU state will be destroyed by
> QEMU, the missed cleanup is no great loss.
> 
> Cc: Laszlo Ersek 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Igor Mammedov 
> Cc: Boris Ostrovsky 
> Cc: Aaron Young 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
> Signed-off-by: Ankur Arora 
> ---
> 
> Notes:
> Addresses the following reviewing comments from v6:
> (1) s/CpuEject/EjectCpu/g
> (2,2a,2c) Get rid of eject-worker and related.
> (2b,2d) Use the PlatformSmmBspElection() logic to find out IsBSP.
> (3,3b) Use CPU_HOT_EJECT_DATA->QemuSelector instead of ApicIdMap to
>  do the actual ejection.
> (4,5a,5b) Fix the format etc in the final unplugged log message
> () Also as discussed elsewhere document the ordering requirements for
>  mCpuHotEjectData->QemuSelector[] and mCpuHotEjectData->Handler.
> () [from patch 2] Move definition of QEMU_CPUHP_STAT_EJECTED to this
>  patch.
> () s/QEMU_CPUHP_STAT_EJECTED/QEMU_CPUHP_STAT_EJECT/
> 
>  OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h  |   1 +
>  OvmfPkg/CpuHotplugSmm/CpuHotplug.c | 127 
> +++--
>  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  |  31 +
>  3 files changed, 152 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h 
> b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
> index 2ec7a107a64d..d0e83102c13f 100644
> --- a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
> +++ b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
> @@ -34,6 +34,7 @@
>  #define QEMU_CPUHP_STAT_ENABLEDBIT0
>  #define QEMU_CPUHP_STAT_INSERT BIT1
>  #define QEMU_CPUHP_STAT_REMOVE BIT2
> +#define QEMU_CPUHP_STAT_EJECT  BIT3
>  #define QEMU_CPUHP_STAT_FW_REMOVE  BIT4
>  
>  #define QEMU_CPUHP_RW_CMD_DATA   0x8
> diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c 
> b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
> index 851e2b28aad9..0484be8fe43c 100644
> --- a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
> +++ b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
> @@ -18,6 +18,7 @@
>  #include  // CPU_HOT_EJECT_DATA
>  #include // EFI_MM_CPU_IO_PROTOCOL
>  #include   // EFI_SMM_CPU_SERVICE_PROTOCOL
> +#include  // MSR_IA32_APIC_BASE_REGISTER
>  #include// EFI_STATUS
>  
>  #include "ApicId.h"  // APIC_ID
> @@ -191,12 +192,39 @@ RevokeNewSlot:
>  }
>  
>  /**
> +  EjectCpu needs to know the BSP at SMI exit at a point when
> +  some of the EFI_SMM_CPU_SERVICE_PROTOCOL state has been torn
> +  down.
> +  Reuse the logic from OvmfPkg::PlatformSmmBspElection() to
> +  do that.
> +
> +  @param[in] ProcessorNum  ProcessorNum denotes the processor handle 
> number
> +   in EFI_SMM_CPU_SERVICE_PROTOCOL.
> +**/
> +STATIC
> +BOOLEAN
> +CheckIfBsp (
> +  IN UINTN ProcessorNum
> +  )

(1a) Please remove the ProcessorNum parameter -- comment and parameter
list alike --; it's useless. In the parameter list, just replace the
line's contents with "VOID".

(1b) Additionally, please state:

  @retval TRUE   If the CPU executing this function is the BSP.

  @retval FALSE  If the CPU executing this function is an AP.




> +{
> +  MSR_IA32_APIC_BASE_REGISTER ApicBaseMsr;
> +  BOOLEAN IsBsp;

(2) "IsBsp" should line up with "ApicBaseMsr".


> +
> +  ApicBaseMsr.Uint64 = AsmReadMsr64 (MSR_IA32_APIC_BASE);
> +  IsBsp = (BOOLEAN)(ApicBaseMsr.Bits.BSP == 1);
> +  return IsBsp;
> +}
> +
> +/**
>CPU Hot-eject handler, called from SmmCpuFeaturesRendezvousExit()
>on each CPU at exit from SMM.
>  
> -  If, the executing CPU is not being ejected, nothing to be done.
> +  If, the executing CPU is neither the BSP, nor being ejected, nothing
> +  to be done.
>If, the executing CPU is being ejected, wait in a halted loop
>until ejected.
> +  If, the executing CPU is the BSP, set QEMU CPU status to eject
> +  for CPUs being ejected.
>  
>@param[in] ProcessorNum  ProcessorNum denotes the CPU exiting SMM,
> and will be used as an index into
> @@ -211,9 +239,99 @@ EjectCpu (
>)
>  {
>UINT64 QemuSelector;
> +  BOOLEAN IsBsp;
>  
> +  IsBsp = CheckIfBs

Re: [edk2-devel] [PATCH v8 08/10] OvmfPkg/CpuHotplugSmm: add EjectCpu()

2021-02-23 Thread Ankur Arora

On 2021-02-23 12:36 p.m., Laszlo Ersek wrote:

superficial comments only; the patch is nearly ready:

On 02/22/21 08:19, Ankur Arora wrote:

Add EjectCpu(), which handles the CPU ejection, and provides a holding
area for said CPUs. It is called via SmmCpuFeaturesRendezvousExit(),
at the tail end of the SMI handling.

Also UnplugCpus() now stashes QEMU Selectors of CPUs which need to be
ejected in CPU_HOT_EJECT_DATA.QemuSelectorMap. This is used by
EjectCpu() to identify CPUs marked for ejection.

Cc: Laszlo Ersek 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Igor Mammedov 
Cc: Boris Ostrovsky 
Cc: Aaron Young 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora 
---

Notes:
 Address these review comments from v6:
  (1) s/CpuEject/EjectCpu/g
  (2) Ensure that the added include is in sorted order.
  (3) Switch to a cheaper CpuSleep() based loop instead of
   CpuDeadLoop().  Also add the CpuLib LibraryClass.
  (4) Remove the nested else clause
  (5) Use Laszlo's much clearer comment when we try to map multiple
   QemuSelector to the same ProcessorNum.
  (6a) Fix indentation of the debug print in the block in (5).
  (6b,6c,6d) Fix printf types for ProcessorNum, use FMT_APIC_ID for
   APIC_ID and 0x%Lx for QemuSelector[].
  () As discussed elsewhere add an DEBUG_INFO print logging the
   correspondence between ProcessorNum, APIC_ID, QemuSelector.
  (7a,7b) Use EFI_ALREADY_STARTED instead of EFI_INVALID_PARAMETER and
   document it in the UnplugCpus() comment block.
  ()  As discussed elsewhere, add the import statement for
   PcdCpuHotEjectDataAddress.
  (9) Use Laszlo's comment in the PcdGet64(PcdCpuHotEjectDataAddress)
   description block.
  (10) Change mCpuHotEjectData init state checks from ASSERT to ones
   consistent with similar checks for mCpuHotPlugData.
  (11-14) Get rid of mCpuHotEjectData init loop: moved to a prior
   patch so it can be done at allocation time.
  (15) s/SmmCpuFeaturesSmiRendezvousExit/SmmCpuFeaturesRendezvousExit/
  (16,17) Document the ordering requirements of
   mCpuHotEjectData->Handler, and mCpuHotEjectData->QemuSelectorMap.

 Not addressed:
  (8) Not removing the EjectCount variable as I'd like to minimize
   stores/loads to CPU_HOT_EJECT_DATA->Handler and so would like to do this
   a single time at the end of the iteration.  (It is safe to write multiple
   times to the handler in UnplugCpus() but given the ordering concerns
   around it, it seems cleaner to not access it unnecessarily.)

  OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf |   2 +
  OvmfPkg/CpuHotplugSmm/CpuHotplug.c  | 157 ++--
  2 files changed, 151 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf 
b/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
index 04322b0d7855..ebcc7e2ac63a 100644
--- a/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
+++ b/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
@@ -40,6 +40,7 @@ [Packages]
  [LibraryClasses]
BaseLib
BaseMemoryLib
+  CpuLib
DebugLib
LocalApicLib
MmServicesTableLib
@@ -54,6 +55,7 @@ [Protocols]

  [Pcd]
gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugDataAddress## 
CONSUMES
+  gUefiOvmfPkgTokenSpaceGuid.PcdCpuHotEjectDataAddress  ## CONSUMES
gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase ## 
CONSUMES

  [FeaturePcd]
diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c 
b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
index f07b5072749a..851e2b28aad9 100644
--- a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
+++ b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
@@ -10,10 +10,12 @@
  #include  // ICH9_APM_CNT
  #include  // QEMU_CPUHP_CMD_GET_PENDING
  #include  // CpuDeadLoop()
+#include   // CpuSleep()
  #include // ASSERT()
  #include   // gMmst
  #include   // PcdGetBool()
  #include   // SafeUintnSub()
+#include  // CPU_HOT_EJECT_DATA
  #include // EFI_MM_CPU_IO_PROTOCOL
  #include   // EFI_SMM_CPU_SERVICE_PROTOCOL
  #include// EFI_STATUS
@@ -32,11 +34,12 @@ STATIC EFI_MM_CPU_IO_PROTOCOL *mMmCpuIo;
  //
  STATIC EFI_SMM_CPU_SERVICE_PROTOCOL *mMmCpuService;
  //
-// This structure is a communication side-channel between the
+// These structures serve as communication side-channels between the
  // EFI_SMM_CPU_SERVICE_PROTOCOL consumer (i.e., this driver) and provider
  // (i.e., PiSmmCpuDxeSmm).
  //
  STATIC CPU_HOT_PLUG_DATA *mCpuHotPlugData;
+STATIC CPU_HOT_EJECT_DATA *mCpuHotEjectData;
  //
  // SMRAM arrays for fetching the APIC IDs of processors with pending events 
(of
  // known event types), for the time of just one MMI.
@@ -188,18 +191,72 @@ RevokeNewSlot:
  }

  /**
+  CPU Hot-eject handler, called from SmmCpuFeaturesRendezvousExit()
+  on each CPU at exit from SMM.
+
+  If, the executing CPU is not 

Re: [edk2-devel] [PATCH v8 07/10] OvmfPkg/SmmCpuFeaturesLib: call CPU hot-eject handler

2021-02-23 Thread Ankur Arora

On 2021-02-23 9:18 a.m., Paolo Bonzini wrote:

On 23/02/21 18:06, Laszlo Ersek wrote:

On 02/23/21 08:45, Paolo Bonzini wrote:

On 22/02/21 15:53, Laszlo Ersek wrote:

+
+  if (mCpuHotEjectData != NULL) {
+    CPU_HOT_EJECT_HANDLER Handler;
+
+    Handler = mCpuHotEjectData->Handler;

This patch looks otherwise OK to me, but:

In patch v8 08/10, we have a ReleaseMemoryFence(). (For now, it is only
expressed as a MemoryFence() call; we'll make that more precise later.)

(1) I think that should be paired with an AcquireMemoryFence() call,
just before loading "mCpuHotEjectData->Handler" above -- for now, also
expressed as a MemoryFence() call only.


In Linux terms, there is a control dependency here.  However, it should
at least be a separate statement to load mCpuHotEjectData (which from my
EDK2 reminiscences should be a global) into a local variable.  So

   EjectData = mCPUHotEjectData;
   // Optional AcquireMemoryFence here
   if (EjectData != NULL) {
 CPU_HOT_EJECT_HANDLER Handler;

 Handler = EjectData->Handler;
 if (Handler != NULL) {
   Handler (CpuIndex);
 }
   }


Yes, "mCPUHotEjectData" is a global.

"mCpuHotEjectData" itself is set up on the BSP (from the entry point
function of the PiSmmCpuSmmDxe driver), before any other APs have a
chance to execute any SMM-related code at all. Furthermore, once set up,
mCpuHotEjectData never changes -- it remains set to a particular
non-NULL value forever, or it remains NULL forever. (The latter case
applies when the possible CPU count is 1; IOW, then there is no AP at all.)


Ok, that's what I was missing.  However, your code below has *two* loads of 
mCpuHotEjectData and the fence would have to go after the second (between the load of 
mCpuHotEjectData and the load of the Handler field).  Therefore I would still use a local 
variable even if you decide to put the fence inside the "if", which I agree is 
the clearest.


Sorry, I'm missing something here. As Laszlo said given that mCpuHotEjectData
does not change after being set, so why would it be a problem in referencing it
twice?

The generated code looks like this (load for mCpuHotEjectData at 0xf54b and
then the dependent mCpuHotEjectData->Handler load on 0xf645):

  # 17d60 
f54b:   48 8b 05 0e 88 00 00mov0x880e(%rip),%rax
f54e: R_X86_64_PC32 .data+0x1d5c
f552:   48 85 c0test   %rax,%rax
f555:   0f 85 ea 00 00 00   jnef645 

  # Handler = mCpuHotEjectData->Handler
f645:   48 8b 40 08 mov0x8(%rax),%rax
f649:   48 85 c0test   %rax,%rax
f64c:   74 05   je f653 
f64e:   4c 89 e1mov%r12,%rcx
f651:   ff d0   callq  *%rax

In the worst case, however, maybe it looks like this (two loads for
mCpuHotEjectData and then the dependent load):

  # 17d60 
f54b:   48 8b 05 0e 88 00 00mov0x880e(%rip),%rax
f54e: R_X86_64_PC32 .data+0x1d5c
f552:   48 85 c0test   %rax,%rax
f555:   0f 85 ea 00 00 00   jnef645 

  # 17d60 
f645:   48 8b 05 0e 88 00 00mov0x880e(%rip),%rax
  +3: R_X86_64_PC32 .data+0x1d5c

  # Handler = mCpuHotEjectData->Handler
  +7:   48 8b 40 08 mov0x8(%rax),%rax
 +11:   48 85 c0test   %rax,%rax
 +14:   74 05   je f653 
 +16:   4c 89 e1mov%r12,%rcx
 +19:   ff d0   callq  *%rax

As you and Laszlo say -- we do need an acquire fence before this line
(which corresponds to the release fence in UnplugCpus(), patch 8
and the release fence in EjectCpu() in patch 9).

 # Handler = mCpuHotEjectData->Handler
  48 8b 40 08 mov0x8(%rax),%rax

A local variable for mCpuHotEjectData, would be nice to have but I'm
not sure it is needed for correctness.

Ankur


Paolo


Because of that, I thought that the first comparison (mCpuHotEjectData
!= NULL) would not need any fence -- I thought it was similar to a
userspace program that (a) set a global variable in the "main" thread,
before calling pthread_create(), (b) treated the global variable as a
constant, ever after (meaning all threads).

However, mCpuHotEjectData->Handler is changed regularly (modified by the
BSP, and read "later" by all processors). That's why I thought the
acquire fence was needed in the following location:

   if (mCpuHotEjectData != NULL) {
 CPU_HOT_EJECT_HANDLER Handler;

 //
 // HERE -- AcquireMemoryFence()
 //
 Handler = mCpuHotEjectData->Handler;
 if (Handler != NULL) {
   Handler (CpuIndex);
 }
   }

Thanks!
Laszlo






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72114): https://edk2.groups.io/g/devel/message/72114
Mute This Topic: https://groups.io/mt/80819862/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mai

Re: [edk2-devel] [PATCH v8 08/10] OvmfPkg/CpuHotplugSmm: add EjectCpu()

2021-02-23 Thread Laszlo Ersek
superficial comments only; the patch is nearly ready:

On 02/22/21 08:19, Ankur Arora wrote:
> Add EjectCpu(), which handles the CPU ejection, and provides a holding
> area for said CPUs. It is called via SmmCpuFeaturesRendezvousExit(),
> at the tail end of the SMI handling.
>
> Also UnplugCpus() now stashes QEMU Selectors of CPUs which need to be
> ejected in CPU_HOT_EJECT_DATA.QemuSelectorMap. This is used by
> EjectCpu() to identify CPUs marked for ejection.
>
> Cc: Laszlo Ersek 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Igor Mammedov 
> Cc: Boris Ostrovsky 
> Cc: Aaron Young 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
> Signed-off-by: Ankur Arora 
> ---
>
> Notes:
> Address these review comments from v6:
>  (1) s/CpuEject/EjectCpu/g
>  (2) Ensure that the added include is in sorted order.
>  (3) Switch to a cheaper CpuSleep() based loop instead of
>   CpuDeadLoop().  Also add the CpuLib LibraryClass.
>  (4) Remove the nested else clause
>  (5) Use Laszlo's much clearer comment when we try to map multiple
>   QemuSelector to the same ProcessorNum.
>  (6a) Fix indentation of the debug print in the block in (5).
>  (6b,6c,6d) Fix printf types for ProcessorNum, use FMT_APIC_ID for
>   APIC_ID and 0x%Lx for QemuSelector[].
>  () As discussed elsewhere add an DEBUG_INFO print logging the
>   correspondence between ProcessorNum, APIC_ID, QemuSelector.
>  (7a,7b) Use EFI_ALREADY_STARTED instead of EFI_INVALID_PARAMETER and
>   document it in the UnplugCpus() comment block.
>  ()  As discussed elsewhere, add the import statement for
>   PcdCpuHotEjectDataAddress.
>  (9) Use Laszlo's comment in the PcdGet64(PcdCpuHotEjectDataAddress)
>   description block.
>  (10) Change mCpuHotEjectData init state checks from ASSERT to ones
>   consistent with similar checks for mCpuHotPlugData.
>  (11-14) Get rid of mCpuHotEjectData init loop: moved to a prior
>   patch so it can be done at allocation time.
>  (15) s/SmmCpuFeaturesSmiRendezvousExit/SmmCpuFeaturesRendezvousExit/
>  (16,17) Document the ordering requirements of
>   mCpuHotEjectData->Handler, and mCpuHotEjectData->QemuSelectorMap.
>
> Not addressed:
>  (8) Not removing the EjectCount variable as I'd like to minimize
>   stores/loads to CPU_HOT_EJECT_DATA->Handler and so would like to do this
>   a single time at the end of the iteration.  (It is safe to write 
> multiple
>   times to the handler in UnplugCpus() but given the ordering concerns
>   around it, it seems cleaner to not access it unnecessarily.)
>
>  OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf |   2 +
>  OvmfPkg/CpuHotplugSmm/CpuHotplug.c  | 157 
> ++--
>  2 files changed, 151 insertions(+), 8 deletions(-)
>
> diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf 
> b/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
> index 04322b0d7855..ebcc7e2ac63a 100644
> --- a/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
> +++ b/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
> @@ -40,6 +40,7 @@ [Packages]
>  [LibraryClasses]
>BaseLib
>BaseMemoryLib
> +  CpuLib
>DebugLib
>LocalApicLib
>MmServicesTableLib
> @@ -54,6 +55,7 @@ [Protocols]
>
>  [Pcd]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugDataAddress## 
> CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdCpuHotEjectDataAddress  ## 
> CONSUMES
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase ## 
> CONSUMES
>
>  [FeaturePcd]
> diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c 
> b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
> index f07b5072749a..851e2b28aad9 100644
> --- a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
> +++ b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
> @@ -10,10 +10,12 @@
>  #include  // ICH9_APM_CNT
>  #include  // QEMU_CPUHP_CMD_GET_PENDING
>  #include  // CpuDeadLoop()
> +#include   // CpuSleep()
>  #include // ASSERT()
>  #include   // gMmst
>  #include   // PcdGetBool()
>  #include   // SafeUintnSub()
> +#include  // CPU_HOT_EJECT_DATA
>  #include // EFI_MM_CPU_IO_PROTOCOL
>  #include   // EFI_SMM_CPU_SERVICE_PROTOCOL
>  #include// EFI_STATUS
> @@ -32,11 +34,12 @@ STATIC EFI_MM_CPU_IO_PROTOCOL *mMmCpuIo;
>  //
>  STATIC EFI_SMM_CPU_SERVICE_PROTOCOL *mMmCpuService;
>  //
> -// This structure is a communication side-channel between the
> +// These structures serve as communication side-channels between the
>  // EFI_SMM_CPU_SERVICE_PROTOCOL consumer (i.e., this driver) and provider
>  // (i.e., PiSmmCpuDxeSmm).
>  //
>  STATIC CPU_HOT_PLUG_DATA *mCpuHotPlugData;
> +STATIC CPU_HOT_EJECT_DATA *mCpuHotEjectData;
>  //
>  // SMRAM arrays for fetching the APIC IDs of processors with pending events 
> (of
>  // known event types), for the time of just one MMI.
> @@ -188,18 +191,72 @@ RevokeNewSlot:
>  }
>
>  /**
> +  CPU Hot-eject

Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition and null instance

2021-02-23 Thread Kun Qin
Hi Hao,

Thanks for the suggestion. I can move the library to MdePkg similar to 
SmmMemLib and add the change for OVMF.

Liming/Zhiguang,

I am happy to prepare patches to cover the dependency change in ed2-platform in 
a separate patch series. But please let me know if you would like to proceed 
otherwise.

Thanks,
Kun

From: Wu, Hao A
Sent: Monday, February 22, 2021 17:42
To: Kun Qin; 
devel@edk2.groups.io; Yao, 
Jiewen; 
gaoliming; Kinney, Michael 
D; Liu, 
Zhiguang
Cc: Wang, Jian J; Dong, 
Eric; Ni, Ray
Subject: Re: [edk2-devel] [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: 
Added definition and null instance

Hello Kun,

Sorry for the delayed response.

Except for missing the UNI file for the newly added library, I do not have 
other comment for the implementation at this moment.
But I am wondering if this library can be added into the MdePkg as the case for 
MdePkg\Library\SmmMemLib\
I have looped in Jiewen, Liming and Mike for comments.

Also, since:
* New library dependency for VariableSmmRuntimeDxe.inf
* INF file separation and new library dependency in Tcg2Smm
I think the series needs to prepare the changes for platforms under edk2 (OVMF) 
and edk2-platforms repositories that consume the above 2 modules.
I am not exactly sure on how this should be handled within edk2-platforms, so I 
added Liming and Zhiguang here for comments.

Best Regards,
Hao Wu

From: Kun Qin 
Sent: Tuesday, February 23, 2021 6:15 AM
To: devel@edk2.groups.io; Wu, Hao A 
Cc: Wang, Jian J ; Dong, Eric ; Ni, 
Ray ; Yao, Jiewen 
Subject: RE: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added 
definition and null instance

Hi Hao,

The patch series was resent with intended usage in VariableRuntime and Tcg2 
drivers. Could you please provide feedback on them? Any input is appreciated.

Regards,
Kun

From: Kun Qin
Sent: Tuesday, February 9, 2021 17:25
To: devel@edk2.groups.io
Cc: Jian J Wang; Hao A 
Wu; Eric Dong; Ray 
Ni; Jiewen Yao
Subject: [PATCH v2 1/6] MdeModulePkg: DxeMmUnblockMemoryLib: Added definition 
and null instance

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3168

This interface definition provides an abstraction layer for DXE drivers
to request certain memory blocks to be mapped/unblocked for accessibility
inside MM environment.

Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Eric Dong mailto:eric.d...@intel.com>>
Cc: Ray Ni mailto:ray...@intel.com>>
Cc: Jiewen Yao mailto:jiewen@intel.com>>

Signed-off-by: Kun Qin mailto:ku...@outlook.com>>
---

Notes:
v2:
- Resend with practical usage. No change [Hao]

 MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c   | 40 

 MdeModulePkg/Include/Library/DxeMmUnblockMemoryLib.h | 40 

 MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.inf | 29 
++
 MdeModulePkg/MdeModulePkg.dec|  5 
+++
 MdeModulePkg/MdeModulePkg.dsc|  2 +
 5 files changed, 116 insertions(+)

diff --git 
a/MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c 
b/MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c
new file mode 100644
index ..774a7e41cfb0
--- /dev/null
+++ b/MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemoryLibNull.c
@@ -0,0 +1,40 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an abstraction layer of requesting certain page access 
to be unblocked
+  by MM environment if applicable.
+
+  Copyright (c), Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain data pages to be accessible 
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer caller requests to 
unblock, the address
+  has to be page aligned.
+  @param  NumberOfPages   The number of pages requested to be 
unblocked from MM
+  environment.
+
+  @return EFI_SUCCESS The request goes through successfully.
+  @return EFI_NOT_AVAILABLE_YET   The requested functionality is not produced 
yet.
+  @return EFI_UNSUPPORTED The requested functionality is not supported 
on current platform.
+  @return EFI_SECURITY_VIOLATION  The requested address failed to pass 
security check for
+   

Re: [edk2-devel] [edk2-platforms PATCH v5 0/4] Platform/Qemu/SbsaQemu: Add SMBIOS tables

2021-02-23 Thread Leif Lindholm
On Tue, Feb 23, 2021 at 10:43:38 -0700, Rebecca Cran wrote:
> o Add SMBIOS 3.4.0 tables using ArmPkg/Universal/Smbios.
> o Bump the PcdSmbiosVersion PCD from 0x300 to 0x304 to indicate support
>   for SMBIOS 3.4.0, as is required by SBBR.
> o Add an implementation of OemMiscLib that provides the system
>   information. The serial numbers, asset tags etc. are currently all
>   fixed strings, to allow fwts to pass without errors.
> o Add SMBIOS PCDs to identify the platform. The processor serial
>   number, asset tag and part number are populated because otherwise
>   fwts reports errors.
> 
> Changes between v4 and v5
> 
> o Moved calling FdtHelperCountCpus in SbsaQemuAcpiDxe from 1/4 into 2/4.

For the series:
Reviewed-by: Leif Lindholm 
Pushed as 9fb5174e0a16..71d92a044db0.

(I did trim a couple of trailing blank lines at end of file in 3/4
before pushing.)

> 
> Rebecca Cran (4):
>   SbsaQemu: Add FdtHelperLib
>   SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib
>   Platform/Qemu/SbsaQemu: Add SMBIOS tables
>   Silicon/Qemu: Don't re-use NumCores as loop index in AddMadtTable
> 
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c| 242 
> 
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf  |  53 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |  50 +++-
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   7 +
>  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |  62 +
>  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   1 +
>  Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h  |  24 ++
>  Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c |  62 +
>  Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf   |  28 +++
>  Silicon/Qemu/SbsaQemu/SbsaQemu.dec|  18 ++
>  10 files changed, 493 insertions(+), 54 deletions(-)
>  create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
>  create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
>  create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
>  create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> 
> -- 
> 2.26.2
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72111): https://edk2.groups.io/g/devel/message/72111
Mute This Topic: https://groups.io/mt/80857020/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v1 0/2] Enable EKDII core CI support for Kvmtool

2021-02-23 Thread Sami Mujawar
Hi All,

Is it possible to integrate this patch in the edk2-stable202102 tag?
This series is also acked at 
https://edk2.groups.io/g/devel/message/70710?p=,,,20,0,0,0::Created,,ArmVirtPkg,20,2,0,80094118

I have also created a Bugzilla ticket at ' *Bug 3216* ( 
https://bugzilla.tianocore.org/show_bug.cgi?id=3216 ) - Add platform CI support 
for Kvmtool'

Regards,

Sami Mujawar


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72110): https://edk2.groups.io/g/devel/message/72110
Mute This Topic: https://groups.io/mt/80035811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v3 1/4] UefiCpuPkg/MpInitLib: Use XADD to avoid lock acquire/release

2021-02-23 Thread Michael D Kinney
Reviewed-by: Michael D Kinney 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Tuesday, February 9, 2021 6:17 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Laszlo Ersek ; 
> Kumar, Rahul1 
> Subject: [edk2-devel] [PATCH v3 1/4] UefiCpuPkg/MpInitLib: Use XADD to avoid 
> lock acquire/release
> 
> When AP firstly wakes up, MpFuncs.nasm contains below logic to assign
> an unique ApIndex to each AP according to who comes first:
> ---ASM---
> TestLock:
> xchg   [edi], eax
> cmpeax, NotVacantFlag
> jz TestLock
> 
> movecx, esi
> addecx, ApIndexLocation
> incdword [ecx]
> movebx, [ecx]
> 
> Releaselock:
> moveax, VacantFlag
> xchg   [edi], eax
> ---ASM END---
> 
> "lock inc" cannot be used to increase ApIndex because not only the
> global ApIndex should be increased, but also the result should be
> stored to a local general purpose register EBX.
> 
> This patch learns from the NASM implementation of
> InternalSyncIncrement() to use "XADD" instruction which can increase
> the global ApIndex and store the original ApIndex to EBX in one
> instruction.
> 
> With this patch, OVMF when running in a 255 threads QEMU spends about
> one second to wakeup all APs. Original implementation needs more than
> 10 seconds.
> 
> Signed-off-by: Ray Ni 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> ---
>  .../Library/MpInitLib/Ia32/MpFuncs.nasm   | 20 ++-
>  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 18 ++---
>  2 files changed, 12 insertions(+), 26 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm 
> b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> index 7e81d24aa6..2eaddc93bc 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> @@ -1,5 +1,5 @@
>  
> ;--
>  ;
> 
> -; Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> 
> +; Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
> 
>  ; SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  ;
> 
>  ; Module Name:
> 
> @@ -125,19 +125,11 @@ SkipEnableExecuteDisable:
>  addedi, LockLocation
> 
>  moveax, NotVacantFlag
> 
> 
> 
> -TestLock:
> 
> -xchg   [edi], eax
> 
> -cmpeax, NotVacantFlag
> 
> -jz TestLock
> 
> -
> 
> -movecx, esi
> 
> -addecx, ApIndexLocation
> 
> -incdword [ecx]
> 
> -movebx, [ecx]
> 
> -
> 
> -Releaselock:
> 
> -moveax, VacantFlag
> 
> -xchg   [edi], eax
> 
> +movedi, esi
> 
> +addedi, ApIndexLocation
> 
> +movebx, 1
> 
> +lock xadd  dword [edi], ebx ; EBX = ApIndex++
> 
> +incebx  ; EBX is CpuNumber
> 
> 
> 
>  movedi, esi
> 
>  addedi, StackSizeLocation
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm 
> b/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm
> index aecfd07bc0..5b588f2dcb 100644
> --- a/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm
> +++ b/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm
> @@ -1,5 +1,5 @@
>  
> ;--
>  ;
> 
> -; Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> 
> +; Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
> 
>  ; SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  ;
> 
>  ; Module Name:
> 
> @@ -161,18 +161,12 @@ LongModeStart:
>  addedi, LockLocation
> 
>  movrax, NotVacantFlag
> 
> 
> 
> -TestLock:
> 
> -xchg   qword [edi], rax
> 
> -cmprax, NotVacantFlag
> 
> -jz TestLock
> 
> -
> 
> -leaecx, [esi + ApIndexLocation]
> 
> -incdword [ecx]
> 
> -movebx, [ecx]
> 
> +movedi, esi
> 
> +addedi, ApIndexLocation
> 
> +movebx, 1
> 
> +lock xadd  dword [edi], ebx ; EBX = ApIndex++
> 
> +incebx  ; EBX is CpuNumber
> 
> 
> 
> -Releaselock:
> 
> -movrax, VacantFlag
> 
> -xchg   qword [edi], rax
> 
>  ; program stack
> 
>  movedi, esi
> 
>  addedi, StackSizeLocation
> 
> --
> 2.27.0.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#71517): https://edk2.groups.io/g/devel/message/71517
> Mute This Topic: https://groups.io/mt/80504936/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72109): h

[edk2-devel] [PATCH v3 1/1] BaseTools: Update the NASM CI dependency

2021-02-23 Thread Bret Barkelew
Update the external dependency (consumed by Edk2Tools) version for NASM,
as agreed in recent community meetings:
https://edk2.groups.io/g/devel/message/71289
https://edk2.groups.io/g/devel/message/71070

This is primarily used by CI builds, but may also be used by platforms.

Signed-off-by: Bret Barkelew 
Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
---
 BaseTools/Bin/nasm_ext_dep.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Bin/nasm_ext_dep.yaml b/BaseTools/Bin/nasm_ext_dep.yaml
index 60b1f71b56aa..56703d4c18e7 100644
--- a/BaseTools/Bin/nasm_ext_dep.yaml
+++ b/BaseTools/Bin/nasm_ext_dep.yaml
@@ -13,6 +13,6 @@
   "type": "nuget",
   "name": "mu_nasm",
   "source": "https://api.nuget.org/v3/index.json";,
-  "version": "2.14.02",
+  "version": "2.15.05",
   "flags": ["set_path", "host_specific"]
 }
-- 
2.28.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72108): https://edk2.groups.io/g/devel/message/72108
Mute This Topic: https://groups.io/mt/80857250/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH 1/3] MdeModulePkg/UfsPassThruDxe: Improve Device initialization polling Loop

2021-02-23 Thread Laszlo Ersek
Bandaru,

can you tell us please why you (apparently) refuse to subscribe to this
list -- in spite of the two invites that I have sent you from the
groups.io moderation WebUI?

You are creating unnecessary work for the moderators. They need to
approve your messages one by one, until you actually subscribe to the
list. It's only then that moderators can add you to the permanent
permit-list (i.e., permanently unmoderate you).

I've stopped approving your messages because you silently ignored
(apparently!) both invites that I generated for you. The latest of those
was sent on Feb 17. And that doesn't take into account any other invites
that other moderators may have sent you.

You are abusing the moderation system. Stop it. You are clearly a
recurring contributor, so subscribe already.

It's bad that I'm telling you this here, on the list, under your patch
set. However I also included a similarly detailed explanation/request
when I rejected your pending messages on Feb 17 (just before I would
send you my 2nd invite). You (apparently) completely ignored the
contents of that rejection message, you wouldn't subscribe, you have
just kept posting new patches since. I can't fathom your behavior.

In the same timeframe, I did the same to another contributor (rejected
their pending messages with a detailed explanation / request, and sent
them a 2nd invite too), and they *have* since subscribed. And now I
un-moderated them as well, ~5 minutes ago.

Do you actually *read* the emails that you receive? Or is your spam
filter mistrained?

Laszlo

On 02/22/21 18:02, Purna Chandra Rao Bandaru wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=3217
> 
> Current Ufs Pass thru driver polls for 5us and return success even when
> the timeout occurs.
> There are cards that can take upto 600ms for Init and hence increased
> the time out for fDeviceInit polling loop.
> 
> Signed-off-by: Bandaru 
> Cc: Mateusz Albecki 
> Cc: Ray Ni 
> Cc: Hao A Wu 
> 
> Change-Id: I6cb063b43bdf37790db8e60c3919153cd2f3c086
> ---
>  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c 
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> index 9768c2e6fb..8859578af3 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> @@ -1,6 +1,6 @@
>  /** @file
>  
> -  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.
>Copyright (c) Microsoft Corporation.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> @@ -749,7 +749,7 @@ UfsFinishDeviceInitialization (
>  {
>EFI_STATUS  Status;
>UINT8  DeviceInitStatus;
> -  UINT8  Timeout;
> +  UINT16 Timeout;
>  
>DeviceInitStatus = 0xFF;
>  
> @@ -761,17 +761,23 @@ UfsFinishDeviceInitialization (
>  return Status;
>}
>  
> -  Timeout = 5;
> +  Timeout = 6000; //There are cards that can take upto 600ms.
>do {
> +MicroSecondDelay (100); //Give 100 us and then start polling.
>  Status = UfsReadFlag (Private, UfsFlagDevInit, &DeviceInitStatus);
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
> -MicroSecondDelay (1);
>  Timeout--;
>} while (DeviceInitStatus != 0 && Timeout != 0);
>  
> -  return EFI_SUCCESS;
> +  if (Timeout == 0) {
> +DEBUG ((DEBUG_ERROR, "UfsFinishDeviceInitialization DeviceInitStatus=%x 
> EFI_TIMEOUT \n", DeviceInitStatus));
> +return EFI_TIMEOUT;
> +  } else {
> +DEBUG ((DEBUG_INFO, "UfsFinishDeviceInitialization Timeout left=%x 
> EFI_SUCCESS \n", Timeout));
> +return EFI_SUCCESS;
> +  }
>  }
>  
>  /**
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72107): https://edk2.groups.io/g/devel/message/72107
Mute This Topic: https://groups.io/mt/80841259/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 PATCH v4 1/4] SbsaQemu: Add FdtHelperLib

2021-02-23 Thread Rebecca Cran

On 2/23/21 9:32 AM, Leif Lindholm wrote:

On Tue, Feb 23, 2021 at 07:26:32 -0700, Rebecca Cran wrote:

The CountCpusFromFdt function is now used in two places. Create
FdtHelperLib for this and similar functions.

Signed-off-by: Rebecca Cran 
Reviewed-by: Leif Lindholm 
---
  Platform/Qemu/SbsaQemu/SbsaQemu.dsc |  2 +
  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c |  5 +-
  Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h| 24 
  Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c   | 62 

  Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf | 28 +
  5 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index f6af3f9111ee..8faad3eda217 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -121,6 +121,8 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
# ARM PL011 UART Driver
PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
  
+  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf

+
# Debug Support

PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fb7c1835c3d7..7bf60cd2ded1 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -487,9 +487,12 @@ InitializeSbsaQemuAcpiDxe (
  {
EFI_STATUS Status;
EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
+  UINT32 NumCores;
  
// Parse the device tree and get the number of CPUs

-  CountCpusFromFdt ();
+  NumCores = FdtHelperCountCpus ();
+  Status = PcdSet32S (PcdCoreCount, NumCores);
+  ASSERT_RETURN_ERROR (Status);
  
// Check if ACPI Table Protocol has been installed

Status = gBS->LocateProtocol (


Would this hunk make more sense in 2/4?
(I think it breaks bisect here.)

No further comments on this set, I think is thise moves, the set can
go in.


Umm, yes it should be in 2/4 - apologies. I'll work to improve verifying 
which patches changes are in.


I've just sent out a v5.

--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72106): https://edk2.groups.io/g/devel/message/72106
Mute This Topic: https://groups.io/mt/80851703/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 v5 4/4] Silicon/Qemu: Don't re-use NumCores as loop index in AddMadtTable

2021-02-23 Thread Rebecca Cran
Avoid re-using the NumCores variable as a loop index, in AddMadtTable:
add a new CoreIndex variable for that purpose.

Signed-off-by: Rebecca Cran 
---
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 037c7cff4c18..84120f1c1b51 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -88,6 +88,7 @@ AddMadtTable (
   EFI_PHYSICAL_ADDRESS  PageAddress;
   UINT8 *New;
   UINT32NumCores;
+  UINT32CoreIndex;
 
   // Initialize MADT ACPI Header
   EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER Header = {
@@ -152,13 +153,13 @@ AddMadtTable (
   New += sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER);
 
   // Add new GICC structures for the Cores
-  for (NumCores = 0; NumCores < PcdGet32 (PcdCoreCount); NumCores++) {
+  for (CoreIndex = 0; CoreIndex < PcdGet32 (PcdCoreCount); CoreIndex++) {
 EFI_ACPI_6_0_GIC_STRUCTURE *GiccPtr;
 
 CopyMem (New, &Gicc, sizeof (EFI_ACPI_6_0_GIC_STRUCTURE));
 GiccPtr = (EFI_ACPI_6_0_GIC_STRUCTURE *) New;
-GiccPtr->AcpiProcessorUid = NumCores;
-GiccPtr->MPIDR = GetMpidr (NumCores);
+GiccPtr->AcpiProcessorUid = CoreIndex;
+GiccPtr->MPIDR = GetMpidr (CoreIndex);
 New += sizeof (EFI_ACPI_6_0_GIC_STRUCTURE);
   }
 
-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72105): https://edk2.groups.io/g/devel/message/72105
Mute This Topic: https://groups.io/mt/80857024/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 v5 3/4] Platform/Qemu/SbsaQemu: Add SMBIOS tables

2021-02-23 Thread Rebecca Cran
o Add SMBIOS 3.4.0 tables using ArmPkg/Universal/Smbios.
o Bump the PcdSmbiosVersion PCD from 0x300 to 0x304 to indicate support
  for SMBIOS 3.4.0, as is required by SBBR.
o Add an implementation of OemMiscLib that provides the system
  information. The serial numbers, asset tags etc. are currently all
  fixed strings, to allow fwts to pass without errors.
o Add SMBIOS PCDs to identify the platform. The processor serial
  number, asset tag and part number are populated because otherwise
  fwts reports errors.

Signed-off-by: Rebecca Cran 
Reviewed-by: Leif Lindholm 
---
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 242 
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  53 +
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  48 +++-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf  |   7 +
 Silicon/Qemu/SbsaQemu/SbsaQemu.dec   |  18 ++
 5 files changed, 367 insertions(+), 1 deletion(-)

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
new file mode 100644
index ..11340788aadf
--- /dev/null
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
@@ -0,0 +1,242 @@
+/** @file
+*  OemMiscLib.c
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** Returns whether the specified processor is present or not.
+
+  @param ProcessorIndex The processor index to check.
+
+  @return TRUE if the processor is present, FALSE otherwise.
+**/
+BOOLEAN
+EFIAPI
+OemIsProcessorPresent (
+  UINTN ProcessorIndex
+  )
+{
+  if (ProcessorIndex < FdtHelperCountCpus ()) {
+return TRUE;
+  }
+
+  return FALSE;
+}
+
+/** Gets the CPU frequency of the specified processor.
+
+  @param ProcessorIndex Index of the processor to get the frequency for.
+
+  @return   CPU frequency in Hz
+**/
+UINTN
+EFIAPI
+OemGetCpuFreq (
+  UINT8 ProcessorIndex
+  )
+{
+  return 20; // 2 GHz
+}
+
+/** Gets information about the specified processor and stores it in
+the structures provided.
+
+  @param ProcessorIndex  Index of the processor to get the information for.
+  @param ProcessorStatus Processor status.
+  @param ProcessorCharacteristics Processor characteritics.
+  @param MiscProcessorDataMiscellaneous processor information.
+
+  @return  TRUE on success, FALSE on failure.
+**/
+BOOLEAN
+EFIAPI
+OemGetProcessorInformation (
+  IN  UINTN ProcessorIndex,
+  IN OUT PROCESSOR_STATUS_DATA  *ProcessorStatus,
+  IN OUT PROCESSOR_CHARACTERISTIC_FLAGS *ProcessorCharacteristics,
+  IN OUT OEM_MISC_PROCESSOR_DATA*MiscProcessorData
+  )
+{
+  UINT16 ProcessorCount;
+
+  ProcessorCount = FdtHelperCountCpus ();
+
+  if (ProcessorIndex < ProcessorCount) {
+ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
+ProcessorStatus->Bits.Reserved1   = 0;
+ProcessorStatus->Bits.SocketPopulated = 1;
+ProcessorStatus->Bits.Reserved2   = 0;
+  } else {
+ProcessorStatus->Bits.CpuStatus   = 0; // CPU disabled
+ProcessorStatus->Bits.Reserved1   = 0;
+ProcessorStatus->Bits.SocketPopulated = 0;
+ProcessorStatus->Bits.Reserved2   = 0;
+  }
+
+  ProcessorCharacteristics->ProcessorReserved1  = 0;
+  ProcessorCharacteristics->ProcessorUnknown= 0;
+  ProcessorCharacteristics->Processor64BitCapable   = 1;
+  ProcessorCharacteristics->ProcessorMultiCore  = 0;
+  ProcessorCharacteristics->ProcessorHardwareThread = 0;
+  ProcessorCharacteristics->ProcessorExecuteProtection  = 1;
+  ProcessorCharacteristics->ProcessorEnhancedVirtualization = 0;
+  ProcessorCharacteristics->ProcessorPowerPerformanceCtrl   = 0;
+  ProcessorCharacteristics->Processor128BitCapable = 0;
+  ProcessorCharacteristics->ProcessorArm64SocId = 1;
+  ProcessorCharacteristics->ProcessorReserved2  = 0;
+
+  MiscProcessorData->CurrentSpeed = 2000;
+  MiscProcessorData->MaxSpeed = 2000;
+  MiscProcessorData->CoreCount= 1;
+  MiscProcessorData->CoresEnabled = 1;
+  MiscProcessorData->ThreadCount  = 1;
+
+  return TRUE;
+}
+
+/** Gets the maximum number of processors supported by the platform.
+
+  @return The maximum number of processors.
+**/
+UINT8
+EFIAPI
+OemGetMaxProcessors (
+  VOID
+  )
+{
+  return FdtHelperCountCpus ();
+}
+
+/** Gets information about the cache at the specified cache level.
+
+  @param ProcessorIndex The processor to get information for.
+  @param CacheLevel The cache level to get information for.
+  @param DataCache  Whether the cache is a data cache.
+  @param UnifiedCache   Whether the cache is a unified cache.
+  @param SmbiosCacheTable The SMBIOS Type7 cache information structure.
+
+  @return TRUE on success, FALSE on failure.
+**/
+BOOLEAN
+EFIAPI
+OemGetCach

[edk2-devel] [edk2-platforms PATCH v5 1/4] SbsaQemu: Add FdtHelperLib

2021-02-23 Thread Rebecca Cran
The CountCpusFromFdt function is now used in two places. Create
FdtHelperLib for this and similar functions.

Signed-off-by: Rebecca Cran 
Reviewed-by: Leif Lindholm 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc |  2 +
 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h| 24 
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c   | 62 

 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf | 28 +
 4 files changed, 116 insertions(+)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index f6af3f9111ee..8faad3eda217 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -121,6 +121,8 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
+  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
+
   # Debug Support
   
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
new file mode 100644
index ..e9e7281c1342
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
@@ -0,0 +1,24 @@
+/** @file
+*  FdtHelperLib.h
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#ifndef FDT_HELPER_LIB_
+#define FDT_HELPER_LIB_
+
+/** Walks through the Device Tree created by Qemu and counts the number
+of CPUs present in it.
+
+@return The number of CPUs present.
+**/
+EFIAPI
+UINT32
+FdtHelperCountCpus (
+  VOID
+  );
+
+#endif /* FDT_HELPER_LIB_ */
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
new file mode 100644
index ..411f035ee7d8
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
@@ -0,0 +1,62 @@
+/** @file
+*  FdtHelperLib.c
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** Walks through the Device Tree created by Qemu and counts the number
+of CPUs present in it.
+
+@return The number of CPUs present.
+**/
+EFIAPI
+UINT32
+FdtHelperCountCpus (
+  VOID
+  )
+{
+  VOID   *DeviceTreeBase;
+  INT32  Node;
+  INT32  Prev;
+  INT32  CpuNode;
+  UINT32 CpuCount;
+
+  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
+  ASSERT (DeviceTreeBase != NULL);
+
+  // Make sure we have a valid device tree blob
+  ASSERT (fdt_check_header (DeviceTreeBase) == 0);
+
+  CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
+  if (CpuNode <= 0) {
+DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
+return 0;
+  }
+
+  CpuCount = 0;
+
+  // Walk through /cpus node and count the number of subnodes.
+  // The count of these subnodes corresponds to the number of
+  // CPUs created by Qemu.
+  Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
+  while (1) {
+CpuCount++;
+Node = fdt_next_subnode (DeviceTreeBase, Prev);
+if (Node < 0) {
+  break;
+}
+Prev = Node;
+  }
+
+  return CpuCount;
+}
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
new file mode 100644
index ..d84c16f888d1
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
@@ -0,0 +1,28 @@
+#/** @file
+#
+#  Component description file for FdtHelperLib module
+#
+#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+  INF_VERSION= 1.29
+  BASE_NAME  = FdtHelperLib
+  FILE_GUID  = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = FdtHelperLib
+
+[Sources.common]
+  FdtHelperLib.c
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
+
+[FixedPcd]
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72102): https://edk2.groups.io/g/devel/message/72102
Mute This Topic: https://groups.io/mt/80857021/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 v5 0/4] Platform/Qemu/SbsaQemu: Add SMBIOS tables

2021-02-23 Thread Rebecca Cran
o Add SMBIOS 3.4.0 tables using ArmPkg/Universal/Smbios.
o Bump the PcdSmbiosVersion PCD from 0x300 to 0x304 to indicate support
  for SMBIOS 3.4.0, as is required by SBBR.
o Add an implementation of OemMiscLib that provides the system
  information. The serial numbers, asset tags etc. are currently all
  fixed strings, to allow fwts to pass without errors.
o Add SMBIOS PCDs to identify the platform. The processor serial
  number, asset tag and part number are populated because otherwise
  fwts reports errors.

Changes between v4 and v5

o Moved calling FdtHelperCountCpus in SbsaQemuAcpiDxe from 1/4 into 2/4.


Rebecca Cran (4):
  SbsaQemu: Add FdtHelperLib
  SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib
  Platform/Qemu/SbsaQemu: Add SMBIOS tables
  Silicon/Qemu: Don't re-use NumCores as loop index in AddMadtTable

 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c| 242 

 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf  |  53 +
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |  50 +++-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   7 +
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |  62 +
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   1 +
 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h  |  24 ++
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c |  62 +
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf   |  28 +++
 Silicon/Qemu/SbsaQemu/SbsaQemu.dec|  18 ++
 10 files changed, 493 insertions(+), 54 deletions(-)
 create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
 create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
 create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
 create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
 create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf

-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72101): https://edk2.groups.io/g/devel/message/72101
Mute This Topic: https://groups.io/mt/80857020/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 v5 2/4] SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib

2021-02-23 Thread Rebecca Cran
Use FdtHelperCountCpus from FdtHelperLib.

Signed-off-by: Rebecca Cran 
---
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 55 
++--
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |  1 +
 2 files changed, 6 insertions(+), 50 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fb7c1835c3d7..037c7cff4c18 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,55 +26,6 @@
 STATIC INT32 FdtFirstCpuOffset;
 STATIC INT32 FdtCpuNodeSize;
 
-/*
- * A function that walks through the Device Tree created
- * by Qemu and counts the number of CPUs present in it.
- */
-STATIC
-VOID
-CountCpusFromFdt (
-  VOID
-)
-{
-  VOID   *DeviceTreeBase;
-  INT32  Node, Prev;
-  RETURN_STATUS  PcdStatus;
-  INT32  CpuNode;
-  INT32  CpuCount;
-
-  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
-  ASSERT (DeviceTreeBase != NULL);
-
-  // Make sure we have a valid device tree blob
-  ASSERT (fdt_check_header (DeviceTreeBase) == 0);
-
-  CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
-  if (CpuNode <= 0) {
-DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
-return;
-  }
-
-  CpuCount = 0;
-
-  // Walk through /cpus node and count the number of subnodes.
-  // The count of these subnodes corresponds to the number of
-  // CPUs created by Qemu.
-  Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
-  FdtFirstCpuOffset = Prev;
-  while (1) {
-CpuCount++;
-Node = fdt_next_subnode (DeviceTreeBase, Prev);
-if (Node < 0) {
-  break;
-}
-FdtCpuNodeSize = Node - Prev;
-Prev = Node;
-  }
-
-  PcdStatus = PcdSet32S (PcdCoreCount, CpuCount);
-  ASSERT_RETURN_ERROR (PcdStatus);
-}
-
 /*
  * Get MPIDR from device tree passed by Qemu
  */
@@ -487,9 +439,12 @@ InitializeSbsaQemuAcpiDxe (
 {
   EFI_STATUS Status;
   EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
+  UINT32 NumCores;
 
   // Parse the device tree and get the number of CPUs
-  CountCpusFromFdt ();
+  NumCores = FdtHelperCountCpus ();
+  Status = PcdSet32S (PcdCoreCount, NumCores);
+  ASSERT_RETURN_ERROR (Status);
 
   // Check if ACPI Table Protocol has been installed
   Status = gBS->LocateProtocol (
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 127eef029f3c..a58ebfaf76d5 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -34,6 +34,7 @@
   BaseLib
   DebugLib
   DxeServicesLib
+  FdtHelperLib
   FdtLib
   PcdLib
   PrintLib
-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72103): https://edk2.groups.io/g/devel/message/72103
Mute This Topic: https://groups.io/mt/80857022/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] implement about virtio-keyboard

2021-02-23 Thread Zhu Yijun
Hi all,
I boot vm with the virtio keyboard on aarch64. It looks UEFI lacks
support for the virtio keyboard, so I can't do any keyboard input
before the linux kernel driver loads, i.e. edit the grub boot menu. Is
there any plan to support it?
I find UsbKeyboardDevice attach on UsbIO which implements its
protocol interface structure(such as UsbGetInterfaceDescriptor,
UsbAsyncInterruptTransfer) defined by UEFI spec, but virtio not. So is
there some way to implement similar interfaces?

Best regards,
Cheng Mao


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72100): https://edk2.groups.io/g/devel/message/72100
Mute This Topic: https://groups.io/mt/80852197/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2] ShellPkg: add more items for smbiosview -t 3 .

2021-02-23 Thread Mars CC Lin
https://bugzilla.tianocore.org/show_bug.cgi?id=3177
Add ContainedElementCount, ContainedElementRecordLength and
ContainedElements for smbiosview type 3.

Signed-off-by: Mars CC Lin 
Cc: Zhichao Gao 
Cc: Philippe Mathieu-Daude 
Cc: Liming Gao 
---
 .../SmbiosView/PrintInfo.c | 14 ++
 .../SmbiosView/SmbiosViewStrings.uni   |  1 +
 2 files changed, 15 insertions(+)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index a3dc7b68c4..4be6cf2df4 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -280,6 +280,7 @@ SmbiosPrintStructure (
   )

 {

   UINT8 Index;

+  UINT8 Index2 = 0;

   UINT8 *Buffer;

 

   if (Struct == NULL) {

@@ -404,6 +405,19 @@ SmbiosPrintStructure (
   if (Struct->Hdr->Length > 0x12) {

 PRINT_STRUCT_VALUE (Struct, Type3, NumberofPowerCords);

   }

+  if (Struct->Hdr->Length > 0x13) {

+PRINT_STRUCT_VALUE (Struct, Type3, ContainedElementCount);

+  }

+  if (Struct->Hdr->Length > 0x14) {

+PRINT_STRUCT_VALUE (Struct, Type3, ContainedElementRecordLength);

+  }

+  for (Index = 0; Index < Struct->Type3->ContainedElementCount; Index++) {

+ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_CONTAINED_ELEMENT), gShellDebug1HiiHandle, Index+1);

+for (Index2 = 0; Index2< Struct->Type3->ContainedElementRecordLength; 
Index2++) {

+  Print (L"%02X ", Buffer[0x15 + (Index * 
Struct->Type3->ContainedElementRecordLength) + Index2]);

+}

+Print (L"\n");

+  }

 }

 if (AE_SMBIOS_VERSION (0x2, 0x7) && (Struct->Hdr->Length > 0x13)) {

   if (Struct->Hdr->Length > (0x15 + (Struct->Type3->ContainedElementCount 
* Struct->Type3->ContainedElementRecordLength))) {

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
index 8bcba7ccf7..9433e8a25f 100644
--- 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
+++ 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
@@ -93,6 +93,7 @@
 #string STR_SMBIOSVIEW_PRINTINFO_POWER_SUPPLY_STATE #language 
en-US "Power Supply State "

 #string STR_SMBIOSVIEW_PRINTINFO_THERMAL_STATE  #language 
en-US "Thermal state "

 #string STR_SMBIOSVIEW_PRINTINFO_SECURITY_STATUS#language 
en-US "Security Status "

+#string STR_SMBIOSVIEW_PRINTINFO_CONTAINED_ELEMENT  #language 
en-US "Contained Element %d: "

 #string STR_SMBIOSVIEW_PRINTINFO_SUPOPRT#language 
en-US "Support "

 #string STR_SMBIOSVIEW_PRINTINFO_CURRENT#language 
en-US "Current "

 #string STR_SMBIOSVIEW_PRINTINFO_INSTALLED  #language 
en-US "Installed "

-- 
2.29.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72099): https://edk2.groups.io/g/devel/message/72099
Mute This Topic: https://groups.io/mt/80856947/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH] ShellPkg: add more items for smbiosview -t 3 .

2021-02-23 Thread Mars CC Lin
https://bugzilla.tianocore.org/show_bug.cgi?id=3177
Add ContainedElementCount, ContainedElementRecordLength and ContainedElements 
for smbiosview type 3.

Signed-off-by: Mars CC Lin 
Cc: Zhichao Gao 
Cc: Philippe Mathieu-Daude 
Cc: Liming Gao 
---
 .../SmbiosView/PrintInfo.c | 14 ++
 .../SmbiosView/SmbiosViewStrings.uni   |  1 +
 2 files changed, 15 insertions(+)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index a3dc7b68c4..8224b8e002 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -280,6 +280,7 @@ SmbiosPrintStructure (
   )

 {

   UINT8 Index;

+  UINT8 Index2 = 0;

   UINT8 *Buffer;

 

   if (Struct == NULL) {

@@ -404,6 +405,19 @@ SmbiosPrintStructure (
   if (Struct->Hdr->Length > 0x12) {

 PRINT_STRUCT_VALUE (Struct, Type3, NumberofPowerCords);

   }

+  if (Struct->Hdr->Length > 0x13) {

+PRINT_STRUCT_VALUE (Struct, Type3, ContainedElementCount);

+  }

+  if (Struct->Hdr->Length > 0x14) {

+PRINT_STRUCT_VALUE (Struct, Type3, ContainedElementRecordLength);

+  }

+  for (Index = 0; Index < Struct->Type3->ContainedElementCount; Index++) { 
   

+ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_CONTAINED_ELEMENT), gShellDebug1HiiHandle, Index+1);

+for (Index2 = 0; Index2< Struct->Type3->ContainedElementRecordLength; 
Index2++) {

+  Print (L"%02X ", Buffer[0x15 + (Index * 
Struct->Type3->ContainedElementRecordLength) + Index2]);

+}

+Print (L"\n");

+  }

 }

 if (AE_SMBIOS_VERSION (0x2, 0x7) && (Struct->Hdr->Length > 0x13)) {

   if (Struct->Hdr->Length > (0x15 + (Struct->Type3->ContainedElementCount 
* Struct->Type3->ContainedElementRecordLength))) {

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
index 8bcba7ccf7..9433e8a25f 100644
--- 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
+++ 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
@@ -93,6 +93,7 @@
 #string STR_SMBIOSVIEW_PRINTINFO_POWER_SUPPLY_STATE #language 
en-US "Power Supply State "

 #string STR_SMBIOSVIEW_PRINTINFO_THERMAL_STATE  #language 
en-US "Thermal state "

 #string STR_SMBIOSVIEW_PRINTINFO_SECURITY_STATUS#language 
en-US "Security Status "

+#string STR_SMBIOSVIEW_PRINTINFO_CONTAINED_ELEMENT  #language 
en-US "Contained Element %d: "

 #string STR_SMBIOSVIEW_PRINTINFO_SUPOPRT#language 
en-US "Support "

 #string STR_SMBIOSVIEW_PRINTINFO_CURRENT#language 
en-US "Current "

 #string STR_SMBIOSVIEW_PRINTINFO_INSTALLED  #language 
en-US "Installed "

-- 
2.29.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72098): https://edk2.groups.io/g/devel/message/72098
Mute This Topic: https://groups.io/mt/80856945/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] * ShellPkg: add the support to show Contained Element Count, Contained Element Record Length and Contained Elements

2021-02-23 Thread Mars CC Lin
Hi Gao,

I've resend the patch with your suggestion. the title is ShellPkg: add more 
items for smbiosview -t 3.
Since I sent it 2 times, please refer the patch latest time.

Mars


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72097): https://edk2.groups.io/g/devel/message/72097
Mute This Topic: https://groups.io/mt/80003667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] Duplicate Files for StandaloneMmDriverEntryPoint.h

2021-02-23 Thread Laszlo Ersek
Hi Michael,

On 02/22/21 23:11, Michael Kubacki wrote:
> Is there a particular reason two copies of
> StandaloneMmDriverEntryPoint.h exist in the edk2 repo?
> 
> 1. MdePkg
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
> 
> 
> 2. StandaloneMmPkg
> https://github.com/tianocore/edk2/blob/master/StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h
> 
> 
> The only substantial difference (apart from copyright and comment
> differences) is that the StandaloneMmPkg instance contains a function
> declaration for EfiMain().

I believe this may have been an omission in commit d6253d2f9a33
("StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint
driver", 2019-03-11).

At that point, both the library class & instance had been migrated to
MdePkg (commits 7df4764e6a81a and 5866d4992396).

Can you propose a patch (unless I'm wrong, of course)?

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72096): https://edk2.groups.io/g/devel/message/72096
Mute This Topic: https://groups.io/mt/80837636/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] MP Services Protocol : Support Hyper threading or not

2021-02-23 Thread Laszlo Ersek
On 02/23/21 02:17, fanjianf...@byosoft.com.cn wrote:
> " Will EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() make all 8 logical cores do 
> some tasks simultaneously?"
> 
> All APs logical processors excute AP task, not including BSP. Acutally the 
> answer is 7.

Good point :)

Thanks
Laszlo

> 
> Jeff
>  
> From: Laszlo Ersek
> Date: 2021-02-22 18:39
> To: devel; tigerliu
> Subject: Re: [edk2-devel] MP Services Protocol : Support Hyper threading or 
> not
> On 02/22/21 08:08, Tiger Liu(BJ-RD) wrote:
>> Dear All:
>> I have a question about MP Services Protocol.
>> Does it support Hyper-threading technology?
>>
>> For example:
>> A Quad-cores CPU(with HT feature support), actually it is equal to 8 logical 
>> cores.
>> Take assumption 8 logical cores are all healthy and being enabled.
>>
>> So:
>>
>> 1.  Will EFI_MP_SERVICES_PROTOCOL.GetNumberOfProcessors()return total 8 
>> logical processor cores?
>>
>> 2.  Will EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() make all 8 logical 
>> cores do some tasks simultaneously?
>  
> My understanding is "yes", to both questions. Most of the MP stuff deals
> with "logical processors".
>  
>  
> BTW, if you check the EFI_MP_SERVICES_GET_PROCESSOR_INFO prototype, it
> outputs EFI_PROCESSOR_INFORMATION. The latter has the following fields:
>  
>   EFI_CPU_PHYSICAL_LOCATION  Location;
>   EXTENDED_PROCESSOR_INFORMATION ExtendedInformation;
>  
> The former gives you a package/core/thread identification for a
> particular processor number. The latter (optionally) provides a 6-level
> description (package / module / tile / die / core / thread). In each
> information structure, "logical thread" is the finest granularity
> information.
>  
> hth
> Laszlo
>  
>  
>  
> 
>  
>  
>  
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72095): https://edk2.groups.io/g/devel/message/72095
Mute This Topic: https://groups.io/mt/80819705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v8 07/10] OvmfPkg/SmmCpuFeaturesLib: call CPU hot-eject handler

2021-02-23 Thread Paolo Bonzini

On 23/02/21 18:06, Laszlo Ersek wrote:

On 02/23/21 08:45, Paolo Bonzini wrote:

On 22/02/21 15:53, Laszlo Ersek wrote:

+
+  if (mCpuHotEjectData != NULL) {
+    CPU_HOT_EJECT_HANDLER Handler;
+
+    Handler = mCpuHotEjectData->Handler;

This patch looks otherwise OK to me, but:

In patch v8 08/10, we have a ReleaseMemoryFence(). (For now, it is only
expressed as a MemoryFence() call; we'll make that more precise later.)

(1) I think that should be paired with an AcquireMemoryFence() call,
just before loading "mCpuHotEjectData->Handler" above -- for now, also
expressed as a MemoryFence() call only.


In Linux terms, there is a control dependency here.  However, it should
at least be a separate statement to load mCpuHotEjectData (which from my
EDK2 reminiscences should be a global) into a local variable.  So

   EjectData = mCPUHotEjectData;
   // Optional AcquireMemoryFence here
   if (EjectData != NULL) {
     CPU_HOT_EJECT_HANDLER Handler;

     Handler = EjectData->Handler;
     if (Handler != NULL) {
   Handler (CpuIndex);
     }
   }


Yes, "mCPUHotEjectData" is a global.

"mCpuHotEjectData" itself is set up on the BSP (from the entry point
function of the PiSmmCpuSmmDxe driver), before any other APs have a
chance to execute any SMM-related code at all. Furthermore, once set up,
mCpuHotEjectData never changes -- it remains set to a particular
non-NULL value forever, or it remains NULL forever. (The latter case
applies when the possible CPU count is 1; IOW, then there is no AP at all.)


Ok, that's what I was missing.  However, your code below has *two* loads 
of mCpuHotEjectData and the fence would have to go after the second 
(between the load of mCpuHotEjectData and the load of the Handler 
field).  Therefore I would still use a local variable even if you decide 
to put the fence inside the "if", which I agree is the clearest.


Paolo


Because of that, I thought that the first comparison (mCpuHotEjectData
!= NULL) would not need any fence -- I thought it was similar to a
userspace program that (a) set a global variable in the "main" thread,
before calling pthread_create(), (b) treated the global variable as a
constant, ever after (meaning all threads).

However, mCpuHotEjectData->Handler is changed regularly (modified by the
BSP, and read "later" by all processors). That's why I thought the
acquire fence was needed in the following location:

   if (mCpuHotEjectData != NULL) {
 CPU_HOT_EJECT_HANDLER Handler;

 //
 // HERE -- AcquireMemoryFence()
 //
 Handler = mCpuHotEjectData->Handler;
 if (Handler != NULL) {
   Handler (CpuIndex);
 }
   }

Thanks!
Laszlo





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72094): https://edk2.groups.io/g/devel/message/72094
Mute This Topic: https://groups.io/mt/80819862/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v8 07/10] OvmfPkg/SmmCpuFeaturesLib: call CPU hot-eject handler

2021-02-23 Thread Laszlo Ersek
On 02/23/21 08:45, Paolo Bonzini wrote:
> On 22/02/21 15:53, Laszlo Ersek wrote:
>>> +
>>> +  if (mCpuHotEjectData != NULL) {
>>> +    CPU_HOT_EJECT_HANDLER Handler;
>>> +
>>> +    Handler = mCpuHotEjectData->Handler;
>> This patch looks otherwise OK to me, but:
>>
>> In patch v8 08/10, we have a ReleaseMemoryFence(). (For now, it is only
>> expressed as a MemoryFence() call; we'll make that more precise later.)
>>
>> (1) I think that should be paired with an AcquireMemoryFence() call,
>> just before loading "mCpuHotEjectData->Handler" above -- for now, also
>> expressed as a MemoryFence() call only.
> 
> In Linux terms, there is a control dependency here.  However, it should
> at least be a separate statement to load mCpuHotEjectData (which from my
> EDK2 reminiscences should be a global) into a local variable.  So
> 
>   EjectData = mCPUHotEjectData;
>   // Optional AcquireMemoryFence here
>   if (EjectData != NULL) {
>     CPU_HOT_EJECT_HANDLER Handler;
> 
>     Handler = EjectData->Handler;
>     if (Handler != NULL) {
>   Handler (CpuIndex);
>     }
>   }

Yes, "mCPUHotEjectData" is a global.

"mCpuHotEjectData" itself is set up on the BSP (from the entry point
function of the PiSmmCpuSmmDxe driver), before any other APs have a
chance to execute any SMM-related code at all. Furthermore, once set up,
mCpuHotEjectData never changes -- it remains set to a particular
non-NULL value forever, or it remains NULL forever. (The latter case
applies when the possible CPU count is 1; IOW, then there is no AP at all.)

Because of that, I thought that the first comparison (mCpuHotEjectData
!= NULL) would not need any fence -- I thought it was similar to a
userspace program that (a) set a global variable in the "main" thread,
before calling pthread_create(), (b) treated the global variable as a
constant, ever after (meaning all threads).

However, mCpuHotEjectData->Handler is changed regularly (modified by the
BSP, and read "later" by all processors). That's why I thought the
acquire fence was needed in the following location:

  if (mCpuHotEjectData != NULL) {
CPU_HOT_EJECT_HANDLER Handler;

//
// HERE -- AcquireMemoryFence()
//
Handler = mCpuHotEjectData->Handler;
if (Handler != NULL) {
  Handler (CpuIndex);
}
  }

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72093): https://edk2.groups.io/g/devel/message/72093
Mute This Topic: https://groups.io/mt/80819862/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2 0/2] TigerlakeOpenBoard: Fix build errors with GCC5

2021-02-23 Thread Takuto Naito
Hi Nate and Heng,

The RELEASE build now succeeds, but I noticed that DEBUG build still fails.
I'm trying to fix it. Do you need me to submit another BZ ticket or use the
same ticket?

Best regards,
Takuto Naito

On Tue, Feb 23, 2021 at 7:27 AM Desimone, Nathaniel L <
nathaniel.l.desim...@intel.com> wrote:

> The series has been pushed as 12ef75d~.. 9fb5174
>
> Thanks,
> Nate
>
> > -Original Message-
> > From: Takuto Naito 
> > Sent: Sunday, February 21, 2021 7:10 AM
> > To: devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V ; Desimone,
> > Nathaniel L ; Luo, Heng
> > 
> > Subject: [PATCH v2 0/2] TigerlakeOpenBoard: Fix build errors with GCC5
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3224
> > TigerlakeOpenBoard: Fix build errors with GCC5
> >
> > v2:
> > - Split the v1 patch into 2 patches.
> >   One is for Platform/Intel/TigerlakeOpenBoardPkg,
> >   another one is for edk2-platforms\Silicon\Intel\TigerlakeSiliconPkg.
> >
> > https://github.com/naitaku/edk2-
> > platforms/tree/tigerlake_fix_build_error_v2
> >
> > Cc: Sai Chaganty 
> > Cc: Nate DeSimone 
> > Cc: Heng Luo 
> >
> > Takuto Naito (2):
> >   TigerlakeOpenBoardPkg: Fix build errors with GCC5
> >   TigerlakeSiliconPkg/IpBlock: Fix build errors with GCC5
> >
> >  .../PeiFspPolicyInitLib.inf   |   2 +-
> >  .../BasePlatformHookLib/BasePlatformHookLib.c | 188 --
> >  .../DxeSiliconPolicyUpdateLate.c  |   2 +-
> >  .../DxePchPcieRpPolicyLib.c   |   2 +-
> >  4 files changed, 3 insertions(+), 191 deletions(-)
> >
> > --
> > 2.30.1
>
> --
内藤 卓人
Takuto Naito


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72092): https://edk2.groups.io/g/devel/message/72092
Mute This Topic: https://groups.io/mt/80801576/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v8 07/10] OvmfPkg/SmmCpuFeaturesLib: call CPU hot-eject handler

2021-02-23 Thread Laszlo Ersek
On 02/23/21 08:37, Ankur Arora wrote:
> On 2021-02-22 6:53 a.m., Laszlo Ersek wrote:
>> Adding Paolo, one comment below:
>>
>> On 02/22/21 08:19, Ankur Arora wrote:
>>> Call the CPU hot-eject handler if one is installed. The condition for
>>> installation is (PcdCpuMaxLogicalProcessorNumber > 1), and there's
>>> a hot-unplug request.
>>>
>>> The handler executes in context of SmmCpuFeaturesRendezvousExit(),
>>> which is called at the tail end of SmiRendezvous() after the BSP has
>>> given the signal to exit via the "AllCpusInSync" loop.
>>>
>>> Cc: Laszlo Ersek 
>>> Cc: Jordan Justen 
>>> Cc: Ard Biesheuvel 
>>> Cc: Igor Mammedov 
>>> Cc: Boris Ostrovsky 
>>> Cc: Aaron Young 
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
>>> Signed-off-by: Ankur Arora 
>>> ---
>>>
>>> Notes:
>>>  Address the following review comments from v6, patch-6:
>>>   (19a) Move the call to the ejection handler to a separate patch.
>>>   (19b) Describe the calling context of
>>> SmmCpuFeaturesRendezvousExit().
>>>   (20) Add comment describing the state when the Handler is not
>>> armed.
>>>
>>>   OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 15
>>> +++
>>>   1 file changed, 15 insertions(+)
>>>
>>> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
>>> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
>>> index adbfc90ad46e..99988285b6a2 100644
>>> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
>>> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
>>> @@ -467,6 +467,21 @@ SmmCpuFeaturesRendezvousExit (
>>>     IN UINTN  CpuIndex
>>>     )
>>>   {
>>> +  //
>>> +  // We only call the Handler if CPU hot-eject is enabled
>>> +  // (PcdCpuMaxLogicalProcessorNumber > 1), and hot-eject is needed
>>> +  // in this SMI exit (otherwise mCpuHotEjectData->Handler is not
>>> armed.)
>>> +  //
>>> +
>>> +  if (mCpuHotEjectData != NULL) {
>>> +    CPU_HOT_EJECT_HANDLER Handler;
>>> +
>>> +    Handler = mCpuHotEjectData->Handler;
>>
>> This patch looks otherwise OK to me, but:
>>
>> In patch v8 08/10, we have a ReleaseMemoryFence(). (For now, it is only
>> expressed as a MemoryFence() call; we'll make that more precise later.)
>>
>> (1) I think that should be paired with an AcquireMemoryFence() call,
>> just before loading "mCpuHotEjectData->Handler" above -- for now, also
>> expressed as a MemoryFence() call only.
>>
>> BTW the first article in Paolo's series has been published:
>>
>>    https://lwn.net/Articles/844224/
>>
>> so in terms of that, we have something similar to this diagram:
>>
>>  thread 1  thread 2
>>    
>>  a.x = 1;
>>  smp_wmb();
>>  WRITE_ONCE(message, &a);  datum = READ_ONCE(message);
>>    smp_rmb();
>>    if (datum != NULL)
>>  printk("%x\n", datum->x);
> 
> Thanks for the link (and Paolo for writing it.) This is great.
> 
>>
>> In patch 8, UnplugCpus() does the first two lines of the "thread 1"
>> (BSP) actions, and the third line is covered by the final "AllCpusInSync
>> = FALSE" assignment in BSPHandler()
>> [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c].
>>
>> Regarding the thread#2 (AP) actions, line#1 is covered by the
>> "AllCpusInSync loop" near the end of SmiRendezvous(). Lines 3+ are
>> covered by our SmmCpuFeaturesRendezvousExit() implementation here. But
>> line#2 (the AcquireMemoryFence()) is missing.
> 
> Yeah you are right. Just think out aloud here... without this it is
> possible
> that on the the AP, the CPU could reorder loads on line-1 and line-3.
> 
> This patch does need an AcquireMemoryFence() (or a MemoryFence() and a
> comment stating that it needs acquire semantics.
> 
> This also makes me realize that although I have somewhat detailed comments
> in patches 8 and 9, but I do need to specify which fence needs to have
> acquire semantics and which release.

If you could do that, that would be awesome. It would make further work
(introducing the more specific fences) much easier.

I'll try to review the remaining patches in v8 still today.

Thanks!
Laszlo

>  
>> ... I'll suspend the review at this point for today; let's see whether
>> we agree on the comments I've made so far. I hope to continue the review
>> tomorrow.
> 
> Agreed so far! And, thanks.
> 
> Ankur
> 
>>
>> Thanks!
>> Laszlo
>>
>>> +
>>> +    if (Handler != NULL) {
>>> +  Handler (CpuIndex);
>>> +    }
>>> +  }
>>>   }
>>>     /**
>>>
>>
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72091): https://edk2.groups.io/g/devel/message/72091
Mute This Topic: https://groups.io/mt/80819862/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v8 02/10] OvmfPkg/CpuHotplugSmm: collect hot-unplug events

2021-02-23 Thread Laszlo Ersek
On 02/22/21 23:03, Ankur Arora wrote:
> On 2021-02-22 4:27 a.m., Laszlo Ersek wrote:
>> On 02/22/21 08:19, Ankur Arora wrote:

>>> diff --git a/OvmfPkg/CpuHotplugSmm/QemuCpuhp.c
>>> b/OvmfPkg/CpuHotplugSmm/QemuCpuhp.c
>>> index 8d4a6693c8d6..36372a5e6193 100644
>>> --- a/OvmfPkg/CpuHotplugSmm/QemuCpuhp.c
>>> +++ b/OvmfPkg/CpuHotplugSmm/QemuCpuhp.c
>>> @@ -164,6 +164,9 @@ QemuCpuhpWriteCommand (
>>>     @param[out] ToUnplugApicIds  The APIC IDs of the CPUs that are
>>> about to be
>>>  hot-unplugged.
>>>   +  @param[out] ToUnplugSelector The QEMU Selectors of the CPUs that
>>> are about to
>>> +   be hot-unplugged.
>>> +
>>>     @param[out] ToUnplugCount    The number of filled-in APIC IDs in
>>>  ToUnplugApicIds.
>>>   
>>
> Acking the comments above.
> 
>> (7) Please (a) call the parameter "ToUnplugSelectors" (plural), and (b)
>> make sure that there are two space characters between the variable name
>> "column" and the documentation "column". (All in all, please move the
>> RHS column to the right by two spaces.)
> 
> That would make the RHS of ToUnplugSelectors not line up with the other
> two out params. (Even though this mail does not seem to show that, they
> do line up in the code.) Is that okay?

Sorry, I was unclear. I meant the request as follows: please move the
full-height RHS column, containing *all* the parameter descriptions, to
the right, by 2 spaces; please also re-wrap wherever necessary, to
maintain <= 80 chars width.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72090): https://edk2.groups.io/g/devel/message/72090
Mute This Topic: https://groups.io/mt/80819858/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 PATCH v4 1/4] SbsaQemu: Add FdtHelperLib

2021-02-23 Thread Leif Lindholm
On Tue, Feb 23, 2021 at 07:26:32 -0700, Rebecca Cran wrote:
> The CountCpusFromFdt function is now used in two places. Create
> FdtHelperLib for this and similar functions.
> 
> Signed-off-by: Rebecca Cran 
> Reviewed-by: Leif Lindholm 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc |  2 +
>  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c |  5 +-
>  Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h| 24 
>  Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c   | 62 
> 
>  Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf | 28 
> +
>  5 files changed, 120 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index f6af3f9111ee..8faad3eda217 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -121,6 +121,8 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
># ARM PL011 UART Driver
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>  
> +  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> +
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
>DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index fb7c1835c3d7..7bf60cd2ded1 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -487,9 +487,12 @@ InitializeSbsaQemuAcpiDxe (
>  {
>EFI_STATUS Status;
>EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
> +  UINT32 NumCores;
>  
>// Parse the device tree and get the number of CPUs
> -  CountCpusFromFdt ();
> +  NumCores = FdtHelperCountCpus ();
> +  Status = PcdSet32S (PcdCoreCount, NumCores);
> +  ASSERT_RETURN_ERROR (Status);
>  
>// Check if ACPI Table Protocol has been installed
>Status = gBS->LocateProtocol (

Would this hunk make more sense in 2/4?
(I think it breaks bisect here.)

No further comments on this set, I think is thise moves, the set can
go in.

/
Leif

> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
> new file mode 100644
> index ..e9e7281c1342
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
> @@ -0,0 +1,24 @@
> +/** @file
> +*  FdtHelperLib.h
> +*
> +*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#ifndef FDT_HELPER_LIB_
> +#define FDT_HELPER_LIB_
> +
> +/** Walks through the Device Tree created by Qemu and counts the number
> +of CPUs present in it.
> +
> +@return The number of CPUs present.
> +**/
> +EFIAPI
> +UINT32
> +FdtHelperCountCpus (
> +  VOID
> +  );
> +
> +#endif /* FDT_HELPER_LIB_ */
> diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c 
> b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
> new file mode 100644
> index ..411f035ee7d8
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
> @@ -0,0 +1,62 @@
> +/** @file
> +*  FdtHelperLib.c
> +*
> +*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> +*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/** Walks through the Device Tree created by Qemu and counts the number
> +of CPUs present in it.
> +
> +@return The number of CPUs present.
> +**/
> +EFIAPI
> +UINT32
> +FdtHelperCountCpus (
> +  VOID
> +  )
> +{
> +  VOID   *DeviceTreeBase;
> +  INT32  Node;
> +  INT32  Prev;
> +  INT32  CpuNode;
> +  UINT32 CpuCount;
> +
> +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
> +  ASSERT (DeviceTreeBase != NULL);
> +
> +  // Make sure we have a valid device tree blob
> +  ASSERT (fdt_check_header (DeviceTreeBase) == 0);
> +
> +  CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
> +  if (CpuNode <= 0) {
> +DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
> +return 0;
> +  }
> +
> +  CpuCount = 0;
> +
> +  // Walk through /cpus node and count the number of subnodes.
> +  // The count of these subnodes corresponds to the number of
> +  // CPUs created by Qemu.
> +  Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
> +  while (1) {
> +CpuCount++;
> +Node = fdt_next_subnode (DeviceTreeBase, Prev);
> +if (Node < 0) {
> +  break;
> +}
> +Prev = Node;
> +  }
> +
> +  return CpuCount;
> +}
> diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.in

Re: [edk2-devel] [PATCH v5 00/14] Add support for using FF-A calls

2021-02-23 Thread Sami Mujawar
Hi Sughosh,

Pushed as a2b5ea38a6fb..68e5ecc4d208

Regards,

Sami Mujawar

From: Sughosh Ganu 
Sent: 22 February 2021 03:19 PM
To: Ard Biesheuvel ; Sami Mujawar 
Cc: devel@edk2.groups.io; Ilias Apalodimas ; 
Laszlo Ersek ; Leif Lindholm ; 
michael.d.kin...@intel.com; Jiewen Yao ; Achin Gupta 

Subject: Re: [PATCH v5 00/14] Add support for using FF-A calls

hi Sami,

On Mon, 22 Feb 2021 at 19:40, Ard Biesheuvel 
mailto:a...@kernel.org>> wrote:
On Fri, 19 Feb 2021 at 07:36, Sughosh Ganu 
mailto:sughosh.g...@linaro.org>> wrote:
>
> The following patch series adds support for using the Firmware
> Framework(FF-A) as a transport mechanism for requesting services from
> the Secure Partition Manager(SPM). This is done through a Pcd which
> can be used to enable the FF-A mechanism or to use the earlier used
> SVC calls.
>
> The patches have been pushed to my github repository[1]
>
> Ran the CI tests through the github draft pull request, and all the CI
> test pass. Ran the PatchCheck script, with no errors.
>
> Changes since V4:
> * Define all variable Pcd's under the [Pcd] section instead of
>   [FixedPcd], as suggested by Liming Gao
>
> Changes since V3:
> * Put the PcdFfaEnable under the PcdsFeatureFlag.AARCH64 section to
>   avoid build breakage for the X64 StandaloneMm builds.
> * Put the macro definitions for the SPM major and minor versions in a
>   separate patch, as suggested by Sami.
> * Separated out the declaration of the SPM major and minor version
>   macros in the earlier patch as was suggested by Sami.
> * Put the macro definitions for the SPM major and minor versions with
>   FF-A support in a separate patch, as suggested by Sami.
> * Declare the PcdFfaEnable Pcd Feature flag under FeaturePcd.AARCH64
>   to avoid build break for the X64 build of StandaloneMm.
> * Change the patch header to have the ArmPkg prefix instead of
>   StandaloneMmMmuLib as suggested by Sami.
>
> Changes since V2:
> * Added a STATIC storage class specifier for mSpmMajorVer and
>   mSpmMinorVer variables
> * Added a STATIC storage class specifier for mSpmMajorVerFfa and
>   mSpmMinorVerFfa variables
> * Add braces for if/else statements
> * Add a check for EFI_NOT_FOUND as a possible return value from
>   LocateStandaloneMmCorePeCoffData in _ModuleEntryPoint function
> * Check for the return value in Arg0 after the Direct Request call to
>   handle errors returned
> * Put a comment to reflect the fact that FFA_INTERRUPT and FFA_SUCCESS
>   response won't be expected in return to a Direct Request call to get
>   the memory attributes
> * Check for the return value in Arg0 after the Direct Request call to
>   handle errors returned
> * Put a comment to reflect the fact that FFA_INTERRUPT and FFA_SUCCESS
>   response won't be expected in return to a Direct Request call to set
>   the memory attributes
>
> Changes since V1:
> Handled review comments from Sami Mujawar
>
> [1] - https://github.com/sughoshg/edk2/tree/implement_ffa_svc_optional_v5
>
>
> Achin Gupta (7):
>   ArmPkg/IndustryStandard: Add barebones FF-A header
>   ArmPkg/ArmSvcLib: Return x4-x7 in output parameters
>   StandaloneMmPkg: Use FF-A header file in Standalone MM Core entry
> point
>   StandaloneMmPkg: Add option to use FF-A calls for communication with
> SPM
>   ArmPkg: Use FF-A header file in Standalone MM Arm MMU library
>   ArmPkg: Allow FF-A calls to get memory region's attributes
>   ArmPkg: Allow FF-A calls to set memory region's attributes
>
> Ilias Apalodimas (2):
>   MdeModulePkg/VariableStandaloneMm: Set PcdFlashNvStorageVariableBase
> to Pcd
>   StandaloneMmPkg: Allow sending FFA Direct Request message to
> StandaloneMm
>
> Sughosh Ganu (5):
>   ArmPkg: Introduce support for PcdFfaEnable
>   ArmPkg: Add macros for SPM version
>   StandaloneMmPkg: Use macros for SPM version check
>   ArmPkg: Add macros for SPM version with FF-A support enabled
>   StandaloneMmPkg: Add option to use FF-A calls for getting SPM version
>

Unfortunately, I won't be able to do a detailed review of this series,
but I have discussed these patches before with Sami off-list, and
based on that and on my earlier review of v3:

Acked-by: Ard Biesheuvel mailto:a...@kernel.org>>

for the series, where necessary.

Can you please merge this patch series for the stable tag edk2-stable202102. I 
have created a bugzilla ticket for this feature addition[1]. Please let me know 
if anything else is needed. Thanks.

-sughosh

[1] - https://bugzilla.tianocore.org/show_bug.cgi?id=3230
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72088): https://edk2.groups.io/g/devel/message/72088
Mute This 

Re: [edk2-devel] implement about virtio-keyboard

2021-02-23 Thread Laszlo Ersek
On 02/23/21 09:48, Zhu Yijun wrote:
> Hi all,
> I boot vm with the virtio keyboard on aarch64. It looks UEFI lacks
> support for the virtio keyboard, so I can't do any keyboard input
> before the linux kernel driver loads, i.e. edit the grub boot menu. Is
> there any plan to support it?

Not on my side.

My team discussed virtio-input's relevance for ArmVirtQemu in September
2016.

We decided not to bother about it, because:

(1) XHCI was virtualization-friendly, both performance-wise and
configuration-wise (unlike EHCI),

(2) QEMU and libvirt were going to gain (... or had just gained ...)
XHCI support, on aarch64 / "virt".


So today, just use a "qemu-xhci" controller in your domain config
please, in combination with a USB keyboard. (If you define a new aarch64
domain with libvirt, this should happen out of the box for you.)

ArmVirtQemu includes all the edk2 drivers necessary for driving those
devices, and ArmVirtQemu's PlatformBootManagerLib instance will connect
the USB keyboard automatically. There shouldn't be a problem when typing
in "grub".

Thanks
Laszlo

> I find UsbKeyboardDevice attach on UsbIO which implements its
> protocol interface structure(such as UsbGetInterfaceDescriptor,
> UsbAsyncInterruptTransfer) defined by UEFI spec, but virtio not. So is
> there some way to implement similar interfaces?
> 
> Best regards,
> Cheng Mao
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72087): https://edk2.groups.io/g/devel/message/72087
Mute This Topic: https://groups.io/mt/80852197/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 4/4] Silicon/Qemu: Don't re-use NumCores as loop index in AddMadtTable

2021-02-23 Thread Rebecca Cran
Avoid re-using the NumCores variable as a loop index, in AddMadtTable:
add a new CoreIndex variable for that purpose.

Signed-off-by: Rebecca Cran 
---
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 037c7cff4c18..84120f1c1b51 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -88,6 +88,7 @@ AddMadtTable (
   EFI_PHYSICAL_ADDRESS  PageAddress;
   UINT8 *New;
   UINT32NumCores;
+  UINT32CoreIndex;
 
   // Initialize MADT ACPI Header
   EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER Header = {
@@ -152,13 +153,13 @@ AddMadtTable (
   New += sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER);
 
   // Add new GICC structures for the Cores
-  for (NumCores = 0; NumCores < PcdGet32 (PcdCoreCount); NumCores++) {
+  for (CoreIndex = 0; CoreIndex < PcdGet32 (PcdCoreCount); CoreIndex++) {
 EFI_ACPI_6_0_GIC_STRUCTURE *GiccPtr;
 
 CopyMem (New, &Gicc, sizeof (EFI_ACPI_6_0_GIC_STRUCTURE));
 GiccPtr = (EFI_ACPI_6_0_GIC_STRUCTURE *) New;
-GiccPtr->AcpiProcessorUid = NumCores;
-GiccPtr->MPIDR = GetMpidr (NumCores);
+GiccPtr->AcpiProcessorUid = CoreIndex;
+GiccPtr->MPIDR = GetMpidr (CoreIndex);
 New += sizeof (EFI_ACPI_6_0_GIC_STRUCTURE);
   }
 
-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72086): https://edk2.groups.io/g/devel/message/72086
Mute This Topic: https://groups.io/mt/80851707/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 3/4] Platform/Qemu/SbsaQemu: Add SMBIOS tables

2021-02-23 Thread Rebecca Cran
o Add SMBIOS 3.4.0 tables using ArmPkg/Universal/Smbios.
o Bump the PcdSmbiosVersion PCD from 0x300 to 0x304 to indicate support
  for SMBIOS 3.4.0, as is required by SBBR.
o Add an implementation of OemMiscLib that provides the system
  information. The serial numbers, asset tags etc. are currently all
  fixed strings, to allow fwts to pass without errors.
o Add SMBIOS PCDs to identify the platform. The processor serial
  number, asset tag and part number are populated because otherwise
  fwts reports errors.

Signed-off-by: Rebecca Cran 
Reviewed-by: Leif Lindholm 
---
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 242 
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  53 +
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  48 +++-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf  |   7 +
 Silicon/Qemu/SbsaQemu/SbsaQemu.dec   |  18 ++
 5 files changed, 367 insertions(+), 1 deletion(-)

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
new file mode 100644
index ..11340788aadf
--- /dev/null
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
@@ -0,0 +1,242 @@
+/** @file
+*  OemMiscLib.c
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** Returns whether the specified processor is present or not.
+
+  @param ProcessorIndex The processor index to check.
+
+  @return TRUE if the processor is present, FALSE otherwise.
+**/
+BOOLEAN
+EFIAPI
+OemIsProcessorPresent (
+  UINTN ProcessorIndex
+  )
+{
+  if (ProcessorIndex < FdtHelperCountCpus ()) {
+return TRUE;
+  }
+
+  return FALSE;
+}
+
+/** Gets the CPU frequency of the specified processor.
+
+  @param ProcessorIndex Index of the processor to get the frequency for.
+
+  @return   CPU frequency in Hz
+**/
+UINTN
+EFIAPI
+OemGetCpuFreq (
+  UINT8 ProcessorIndex
+  )
+{
+  return 20; // 2 GHz
+}
+
+/** Gets information about the specified processor and stores it in
+the structures provided.
+
+  @param ProcessorIndex  Index of the processor to get the information for.
+  @param ProcessorStatus Processor status.
+  @param ProcessorCharacteristics Processor characteritics.
+  @param MiscProcessorDataMiscellaneous processor information.
+
+  @return  TRUE on success, FALSE on failure.
+**/
+BOOLEAN
+EFIAPI
+OemGetProcessorInformation (
+  IN  UINTN ProcessorIndex,
+  IN OUT PROCESSOR_STATUS_DATA  *ProcessorStatus,
+  IN OUT PROCESSOR_CHARACTERISTIC_FLAGS *ProcessorCharacteristics,
+  IN OUT OEM_MISC_PROCESSOR_DATA*MiscProcessorData
+  )
+{
+  UINT16 ProcessorCount;
+
+  ProcessorCount = FdtHelperCountCpus ();
+
+  if (ProcessorIndex < ProcessorCount) {
+ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
+ProcessorStatus->Bits.Reserved1   = 0;
+ProcessorStatus->Bits.SocketPopulated = 1;
+ProcessorStatus->Bits.Reserved2   = 0;
+  } else {
+ProcessorStatus->Bits.CpuStatus   = 0; // CPU disabled
+ProcessorStatus->Bits.Reserved1   = 0;
+ProcessorStatus->Bits.SocketPopulated = 0;
+ProcessorStatus->Bits.Reserved2   = 0;
+  }
+
+  ProcessorCharacteristics->ProcessorReserved1  = 0;
+  ProcessorCharacteristics->ProcessorUnknown= 0;
+  ProcessorCharacteristics->Processor64BitCapable   = 1;
+  ProcessorCharacteristics->ProcessorMultiCore  = 0;
+  ProcessorCharacteristics->ProcessorHardwareThread = 0;
+  ProcessorCharacteristics->ProcessorExecuteProtection  = 1;
+  ProcessorCharacteristics->ProcessorEnhancedVirtualization = 0;
+  ProcessorCharacteristics->ProcessorPowerPerformanceCtrl   = 0;
+  ProcessorCharacteristics->Processor128BitCapable = 0;
+  ProcessorCharacteristics->ProcessorArm64SocId = 1;
+  ProcessorCharacteristics->ProcessorReserved2  = 0;
+
+  MiscProcessorData->CurrentSpeed = 2000;
+  MiscProcessorData->MaxSpeed = 2000;
+  MiscProcessorData->CoreCount= 1;
+  MiscProcessorData->CoresEnabled = 1;
+  MiscProcessorData->ThreadCount  = 1;
+
+  return TRUE;
+}
+
+/** Gets the maximum number of processors supported by the platform.
+
+  @return The maximum number of processors.
+**/
+UINT8
+EFIAPI
+OemGetMaxProcessors (
+  VOID
+  )
+{
+  return FdtHelperCountCpus ();
+}
+
+/** Gets information about the cache at the specified cache level.
+
+  @param ProcessorIndex The processor to get information for.
+  @param CacheLevel The cache level to get information for.
+  @param DataCache  Whether the cache is a data cache.
+  @param UnifiedCache   Whether the cache is a unified cache.
+  @param SmbiosCacheTable The SMBIOS Type7 cache information structure.
+
+  @return TRUE on success, FALSE on failure.
+**/
+BOOLEAN
+EFIAPI
+OemGetCach

[edk2-devel] [edk2-platforms PATCH v4 2/4] SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib

2021-02-23 Thread Rebecca Cran
Use FdtHelperCountCpus from FdtHelperLib.

Signed-off-by: Rebecca Cran 
---
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 50 
+---
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |  1 +
 2 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 7bf60cd2ded1..037c7cff4c18 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,55 +26,6 @@
 STATIC INT32 FdtFirstCpuOffset;
 STATIC INT32 FdtCpuNodeSize;
 
-/*
- * A function that walks through the Device Tree created
- * by Qemu and counts the number of CPUs present in it.
- */
-STATIC
-VOID
-CountCpusFromFdt (
-  VOID
-)
-{
-  VOID   *DeviceTreeBase;
-  INT32  Node, Prev;
-  RETURN_STATUS  PcdStatus;
-  INT32  CpuNode;
-  INT32  CpuCount;
-
-  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
-  ASSERT (DeviceTreeBase != NULL);
-
-  // Make sure we have a valid device tree blob
-  ASSERT (fdt_check_header (DeviceTreeBase) == 0);
-
-  CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
-  if (CpuNode <= 0) {
-DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
-return;
-  }
-
-  CpuCount = 0;
-
-  // Walk through /cpus node and count the number of subnodes.
-  // The count of these subnodes corresponds to the number of
-  // CPUs created by Qemu.
-  Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
-  FdtFirstCpuOffset = Prev;
-  while (1) {
-CpuCount++;
-Node = fdt_next_subnode (DeviceTreeBase, Prev);
-if (Node < 0) {
-  break;
-}
-FdtCpuNodeSize = Node - Prev;
-Prev = Node;
-  }
-
-  PcdStatus = PcdSet32S (PcdCoreCount, CpuCount);
-  ASSERT_RETURN_ERROR (PcdStatus);
-}
-
 /*
  * Get MPIDR from device tree passed by Qemu
  */
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 127eef029f3c..a58ebfaf76d5 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -34,6 +34,7 @@
   BaseLib
   DebugLib
   DxeServicesLib
+  FdtHelperLib
   FdtLib
   PcdLib
   PrintLib
-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72084): https://edk2.groups.io/g/devel/message/72084
Mute This Topic: https://groups.io/mt/80851704/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/4] SbsaQemu: Add FdtHelperLib

2021-02-23 Thread Rebecca Cran
The CountCpusFromFdt function is now used in two places. Create
FdtHelperLib for this and similar functions.

Signed-off-by: Rebecca Cran 
Reviewed-by: Leif Lindholm 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc |  2 +
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c |  5 +-
 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h| 24 
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c   | 62 

 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf | 28 +
 5 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index f6af3f9111ee..8faad3eda217 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -121,6 +121,8 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
+  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
+
   # Debug Support
   
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fb7c1835c3d7..7bf60cd2ded1 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -487,9 +487,12 @@ InitializeSbsaQemuAcpiDxe (
 {
   EFI_STATUS Status;
   EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
+  UINT32 NumCores;
 
   // Parse the device tree and get the number of CPUs
-  CountCpusFromFdt ();
+  NumCores = FdtHelperCountCpus ();
+  Status = PcdSet32S (PcdCoreCount, NumCores);
+  ASSERT_RETURN_ERROR (Status);
 
   // Check if ACPI Table Protocol has been installed
   Status = gBS->LocateProtocol (
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
new file mode 100644
index ..e9e7281c1342
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
@@ -0,0 +1,24 @@
+/** @file
+*  FdtHelperLib.h
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#ifndef FDT_HELPER_LIB_
+#define FDT_HELPER_LIB_
+
+/** Walks through the Device Tree created by Qemu and counts the number
+of CPUs present in it.
+
+@return The number of CPUs present.
+**/
+EFIAPI
+UINT32
+FdtHelperCountCpus (
+  VOID
+  );
+
+#endif /* FDT_HELPER_LIB_ */
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
new file mode 100644
index ..411f035ee7d8
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
@@ -0,0 +1,62 @@
+/** @file
+*  FdtHelperLib.c
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** Walks through the Device Tree created by Qemu and counts the number
+of CPUs present in it.
+
+@return The number of CPUs present.
+**/
+EFIAPI
+UINT32
+FdtHelperCountCpus (
+  VOID
+  )
+{
+  VOID   *DeviceTreeBase;
+  INT32  Node;
+  INT32  Prev;
+  INT32  CpuNode;
+  UINT32 CpuCount;
+
+  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
+  ASSERT (DeviceTreeBase != NULL);
+
+  // Make sure we have a valid device tree blob
+  ASSERT (fdt_check_header (DeviceTreeBase) == 0);
+
+  CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
+  if (CpuNode <= 0) {
+DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
+return 0;
+  }
+
+  CpuCount = 0;
+
+  // Walk through /cpus node and count the number of subnodes.
+  // The count of these subnodes corresponds to the number of
+  // CPUs created by Qemu.
+  Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
+  while (1) {
+CpuCount++;
+Node = fdt_next_subnode (DeviceTreeBase, Prev);
+if (Node < 0) {
+  break;
+}
+Prev = Node;
+  }
+
+  return CpuCount;
+}
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
new file mode 100644
index ..d84c16f888d1
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
@@ -0,0 +1,28 @@
+#/** @file
+#
+#  Component description file for FdtHelperLib module
+#
+#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+  INF_VERSION= 1.29
+  BASE_NAME  = FdtHelperLib
+  FILE_GUID

[edk2-devel] [edk2-platforms PATCH v4 0/4] Platform/Qemu/SbsaQemu: Add SMBIOS tables

2021-02-23 Thread Rebecca Cran
o Add SMBIOS 3.4.0 tables using ArmPkg/Universal/Smbios.
o Bump the PcdSmbiosVersion PCD from 0x300 to 0x304 to indicate support
  for SMBIOS 3.4.0, as is required by SBBR.
o Add an implementation of OemMiscLib that provides the system
  information. The serial numbers, asset tags etc. are currently all
  fixed strings, to allow fwts to pass without errors.
o Add SMBIOS PCDs to identify the platform. The processor serial
  number, asset tag and part number are populated because otherwise
  fwts reports errors.

Changes between v3 and v4

o Renamed function in FdtHelperLib to FdtHelperCountCpus.
o Renamed 'mHiiHandle' parameter in OemUpdateSmbiosInfo to 'HiiHandle'.
o Added a patch to add CoreIndex variable into AddMadtTable.
o Added setting of PcdCoreCount into InitializeSbsaQemuAcpiDxe.


Rebecca Cran (4):
  SbsaQemu: Add FdtHelperLib
  SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib
  Platform/Qemu/SbsaQemu: Add SMBIOS tables
  Silicon/Qemu: Don't re-use NumCores as loop index in AddMadtTable

 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c| 242 

 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf  |  53 +
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |  50 +++-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   7 +
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |  62 +
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   1 +
 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h  |  24 ++
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c |  62 +
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf   |  28 +++
 Silicon/Qemu/SbsaQemu/SbsaQemu.dec|  18 ++
 10 files changed, 493 insertions(+), 54 deletions(-)
 create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
 create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
 create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
 create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
 create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf

-- 
2.26.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72082): https://edk2.groups.io/g/devel/message/72082
Mute This Topic: https://groups.io/mt/80851702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB memory WA

2021-02-23 Thread Ma, Maurice
Hi, Ray, Eric and Jeff,

Sure, I am OK with that too.
 Thank you all for looking into it and provide a solution quickly.

Regards
Maurice
From: Ni, Ray 
Sent: Tuesday, February 23, 2021 1:08
To: Ma, Maurice ; devel@edk2.groups.io; 
fanjianf...@byosoft.com.cn; Patrick Rudolph ; 
Dong, Guo ; Dong, Eric 
Cc: You, Benjamin 
Subject: RE: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA

Maurice,
It’s doable 😊
I prefer to accept today’s below 4G limitation to maintain simple 
implementation.


Thanks,
Ray

From: Ma, Maurice mailto:maurice...@intel.com>>
Sent: Tuesday, February 23, 2021 3:26 PM
To: Ni, Ray mailto:ray...@intel.com>>; 
devel@edk2.groups.io; 
fanjianf...@byosoft.com.cn; Patrick Rudolph 
mailto:patrick.rudo...@9elements.com>>; Dong, 
Guo mailto:guo.d...@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>
Cc: You, Benjamin mailto:benjamin@intel.com>>
Subject: RE: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA

Could we decouple BSP and AP GDT in early waking up stage ?
For example, AP uses temporary GDT (below 4GB) just for mode switching.  Once 
AP is in the final stage,  AP can reload GDT to match BSP.  In this way, we 
don’t have assumption on the final GDT location.

Thanks
Maurice
From: Ni, Ray mailto:ray...@intel.com>>
Sent: Monday, February 22, 2021 21:22
To: devel@edk2.groups.io; 
fanjianf...@byosoft.com.cn; Ma, Maurice 
mailto:maurice...@intel.com>>; Patrick Rudolph 
mailto:patrick.rudo...@9elements.com>>; Dong, 
Guo mailto:guo.d...@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>
Cc: You, Benjamin mailto:benjamin@intel.com>>
Subject: RE: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA

“But we could allocate room under 4G for GDT table directly in CpuDxe.”
The GDT pre-allocated is re-used by AP. Why do you suggest CpuDxe allocate GDT?

Thanks,
Ray

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Jeff Fan
Sent: Tuesday, February 23, 2021 11:43 AM
To: devel@edk2.groups.io; Ni, Ray 
mailto:ray...@intel.com>>; Ma, Maurice 
mailto:maurice...@intel.com>>; Patrick Rudolph 
mailto:patrick.rudo...@9elements.com>>; Dong, 
Guo mailto:guo.d...@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>
Cc: devel@edk2.groups.io; You, Benjamin 
mailto:benjamin@intel.com>>
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA

Ray,

Yes. You are right. Acutally, x64 IDT table cannot work correctly on protected 
mode. :-)

But for GDT location, I agree it should be located under 4G space to support AP 
mode changing.  But we could allocate room under 4G for GDT table directly in 
CpuDxe.

Thanks,
Jeff


From: Ni, Ray
Date: 2021-02-23 10:52
To: fanjianf...@byosoft.com.cn; 
devel; Ma, Maurice; 
Patrick Rudolph; Dong, 
Guo; Dong, Eric
CC: devel@edk2.groups.io; You, 
Benjamin
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB 
memory WA
Jeff,
You are right that BSP’s GDT and IDT tables are under 4G memory.

It’s because when AP wakes up, it needs the GDT for entering protected mode. AP 
cannot access above 4G memory without entering to long mode.

I do agree that the 64bit IDT is not proper for AP when entering protected 
mode. As long as there is no exception in the short time frame (load 64bit IDT, 
before entering long mode), it’s still ok.

Thanks,
Ray

From: fanjianf...@byosoft.com.cn 
mailto:fanjianf...@byosoft.com.cn>>
Sent: Tuesday, February 23, 2021 8:50 AM
To: devel mailto:devel@edk2.groups.io>>; Ma, Maurice 
mailto:maurice...@intel.com>>; Patrick Rudolph 
mailto:patrick.rudo...@9elements.com>>; Dong, 
Guo mailto:guo.d...@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Cc: devel@edk2.groups.io; You, Benjamin 
mailto:benjamin@intel.com>>
Subject: Re: Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 
4GB memory WA

we will save the current BSP's GDT and IDT for APs at first time APs are waken 
by BSP as below. APs will start from real mode to protected mode and then to 
long mode. During protected mode, BSP's GDT/IDT table are working on APs.

In UefiCpuPkg\Library\MpInitLib\MpLib.c,
  //
  // Get the BSP's data of GDT and IDT
  //
  AsmReadGdtr ((IA32_DESCRIPTOR *) &ExchangeInfo->GdtrProfile);
  AsmReadIdtr ((IA32_DESCRIPTOR *) &ExchangeInfo->IdtrProfile);

It seems to be one bug we have assumption on GDT table and IDT tabl

[edk2-devel] [PATCH v3 26/26] ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_PERFORMANCE

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 .../ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h |  4 ++--
 .../Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c   | 12 ++--
 .../Include/Protocol/ArmScmiPerformanceProtocol.h  | 14 +++---
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h 
b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h
index b274b5ab2ad4..b178aa3fdf10 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h
+++ b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -22,7 +22,7 @@
 #define NUM_REMAIN_PERF_LEVELS_SHIFT  16
 #define NUM_REMAIN_PERF_LEVELS(Lvls) (Lvls >> NUM_REMAIN_PERF_LEVELS_SHIFT)
 
-/** Return values for SCMI_MESSAGE_ID_PERFORMANCE_DESCRIBE_LEVELS command.
+/** Return values for ScmiMessageIdPerformanceDescribeLevels command.
   SCMI Spec section 4.5.2.5
 **/
 typedef struct {
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
index 51cad4d2c602..684ed713d52c 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
@@ -108,7 +108,7 @@ PerformanceDomainAttributes (
   *MessageParams = DomainId;
 
   Cmd.ProtocolId = ScmiProtocolIdPerformance;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_PERFORMANCE_DOMAIN_ATTRIBUTES;
+  Cmd.MessageId  = ScmiMessageIdPerformanceDomainAttributes;
 
   PayloadLength = sizeof (DomainId);
 
@@ -180,7 +180,7 @@ PerformanceDescribeLevels (
   *MessageParams++ = DomainId;
 
   Cmd.ProtocolId = ScmiProtocolIdPerformance;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_PERFORMANCE_DESCRIBE_LEVELS;
+  Cmd.MessageId  = ScmiMessageIdPerformanceDescribeLevels;
 
   do {
 
@@ -259,7 +259,7 @@ PerformanceLimitsSet (
   *MessageParams   = Limits->RangeMin;
 
   Cmd.ProtocolId = ScmiProtocolIdPerformance;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_PERFORMANCE_LIMITS_SET;
+  Cmd.MessageId  = ScmiMessageIdPerformanceLimitsSet;
 
   PayloadLength = sizeof (DomainId) + sizeof (SCMI_PERFORMANCE_LIMITS);
 
@@ -305,7 +305,7 @@ PerformanceLimitsGet (
   *MessageParams = DomainId;
 
   Cmd.ProtocolId = ScmiProtocolIdPerformance;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_PERFORMANCE_LIMITS_GET;
+  Cmd.MessageId  = ScmiMessageIdPerformanceLimitsGet;
 
   PayloadLength = sizeof (DomainId);
 
@@ -355,7 +355,7 @@ PerformanceLevelSet (
   *MessageParams   = Level;
 
   Cmd.ProtocolId = ScmiProtocolIdPerformance;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_PERFORMANCE_LEVEL_SET;
+  Cmd.MessageId  = ScmiMessageIdPerformanceLevelSet;
 
   PayloadLength = sizeof (DomainId) + sizeof (Level);
 
@@ -400,7 +400,7 @@ PerformanceLevelGet (
   *MessageParams = DomainId;
 
   Cmd.ProtocolId = ScmiProtocolIdPerformance;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_PERFORMANCE_LEVEL_GET;
+  Cmd.MessageId  = ScmiMessageIdPerformanceLevelGet;
 
   PayloadLength = sizeof (DomainId);
 
diff --git a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
index 96a4d66737bd..8c70aa75281e 100644
--- a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -247,12 +247,12 @@ typedef struct _SCMI_PERFORMANCE_PROTOCOL {
 } SCMI_PERFORMANCE_PROTOCOL;
 
 typedef enum {
-  SCMI_MESSAGE_ID_PERFORMANCE_DOMAIN_ATTRIBUTES = 0x3,
-  SCMI_MESSAGE_ID_PERFORMANCE_DESCRIBE_LEVELS   = 0x4,
-  SCMI_MESSAGE_ID_PERFORMANCE_LIMITS_SET= 0x5,
-  SCMI_MESSAGE_ID_PERFORMANCE_LIMITS_GET= 0x6,
-  SCMI_MESSAGE_ID_PERFORMANCE_LEVEL_SET = 0x7,
-  SCMI_MESSAGE_ID_PERFORMANCE_LEVEL_GET = 0x8,
+  ScmiMessageIdPerformanceDomainAttributes = 0x3,
+  ScmiMessageIdPerformanceDescribeLevels   = 0x4,
+  ScmiMessageIdPerformanceLimitsSet= 0x5,
+  ScmiMessageIdPerformanceLimitsGet= 0x6,
+  ScmiMessageIdPerformanceLevelSet = 0x7,
+  ScmiMessageIdPerformanceLevelGet = 0x8,
 } SCMI_MESSAGE_ID_PERFORMANCE;
 
 #endif /* ARM_SCMI_PERFORMANCE_PROTOCOL_H_ */
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72080

[edk2-devel] [PATCH v3 25/26] ArmPkg: Fix Ecc error 8005 for SCMI_CLOCK_RATE_FORMAT

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c   | 8 
 ArmPkg/Include/Protocol/ArmScmiClock2Protocol.h | 6 +++---
 ArmPkg/Include/Protocol/ArmScmiClockProtocol.h  | 8 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
index 9cd3a7ed232d..cc223d672028 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
@@ -152,10 +152,10 @@ ClockGetClockAttributes (
   @param[in] ThisA pointer to SCMI_CLOCK_PROTOCOL Instance.
   @param[in] ClockId Identifier for the clock device.
 
-  @param[out] Format  SCMI_CLOCK_RATE_FORMAT_DISCRETE: Clock device
+  @param[out] Format  ScmiClockRateFormatDiscrete: Clock device
   supports range of clock rates which are non-linear.
 
-  SCMI_CLOCK_RATE_FORMAT_LINEAR: Clock device supports
+  ScmiClockRateFormatLinear: Clock device supports
   range of linear clock rates from Min to Max in steps.
 
   @param[out] TotalRates  Total number of rates.
@@ -236,7 +236,7 @@ ClockDescribeRates (
   *TotalRates = NUM_RATES (DescribeRates->NumRatesFlags)
 + NUM_REMAIN_RATES (DescribeRates->NumRatesFlags);
 
-  if (*Format == SCMI_CLOCK_RATE_FORMAT_DISCRETE) {
+  if (*Format == ScmiClockRateFormatDiscrete) {
  RequiredArraySize = (*TotalRates) * sizeof (UINT64);
   } else {
  // We need to return triplet of 64 bit value for each rate
@@ -251,7 +251,7 @@ ClockDescribeRates (
 
 RateOffset = 0;
 
-if (*Format == SCMI_CLOCK_RATE_FORMAT_DISCRETE) {
+if (*Format == ScmiClockRateFormatDiscrete) {
   for (RateNo = 0; RateNo < NUM_RATES (DescribeRates->NumRatesFlags); 
RateNo++) {
 Rate = &DescribeRates->Rates[RateOffset++];
 // Non-linear discrete rates.
diff --git a/ArmPkg/Include/Protocol/ArmScmiClock2Protocol.h 
b/ArmPkg/Include/Protocol/ArmScmiClock2Protocol.h
index 950141cbd2da..0e26491a62c4 100644
--- a/ArmPkg/Include/Protocol/ArmScmiClock2Protocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiClock2Protocol.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -89,10 +89,10 @@ EFI_STATUS
   @param[in] ThisA pointer to SCMI_CLOCK2_PROTOCOL Instance.
   @param[in] ClockId Identifier for the clock device.
 
-  @param[out] Format  SCMI_CLOCK_RATE_FORMAT_DISCRETE: Clock device
+  @param[out] Format  ScmiClockRateFormatDiscrete: Clock device
   supports range of clock rates which are non-linear.
 
-  SCMI_CLOCK_RATE_FORMAT_LINEAR: Clock device supports
+  ScmiClockRateFormatLinear: Clock device supports
   range of linear clock rates from Min to Max in steps.
 
   @param[out] TotalRates  Total number of rates.
diff --git a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
index cd62f05a58fd..4210a53cf98d 100644
--- a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
@@ -30,8 +30,8 @@ typedef enum {
 } SCMI_MESSAGE_ID_CLOCK;
 
 typedef enum {
-  SCMI_CLOCK_RATE_FORMAT_DISCRETE, // Non-linear range.
-  SCMI_CLOCK_RATE_FORMAT_LINEAR// Linear range.
+  ScmiClockRateFormatDiscrete, // Non-linear range.
+  ScmiClockRateFormatLinear// Linear range.
 } SCMI_CLOCK_RATE_FORMAT;
 
 // Clock management protocol version.
@@ -139,10 +139,10 @@ EFI_STATUS
   @param[in] ThisA pointer to SCMI_CLOCK_PROTOCOL Instance.
   @param[in] ClockId Identifier for the clock device.
 
-  @param[out] Format  SCMI_CLOCK_RATE_FORMAT_DISCRETE: Clock device
+  @param[out] Format  ScmiClockRateFormatDiscrete: Clock device
   supports range of clock rates which are non-linear.
 
-  SCMI_CLOCK_RATE_FORMAT_LINEAR: Clock device supports
+  ScmiClockRateFormatLinear: Clock device supports
   range of linear clock rates from Min to Max in steps.
 
   @param[out] TotalRates  Total number of rates.
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72079): https://edk2.groups.io/g/devel/message/72079
Mute This 

[edk2-devel] [PATCH v3 24/26] ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_CLOCK

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3


Notes:
v3:
 - Remove ScmiMessageIdBasexxx related changes. [Sami]

 ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c  | 10 +-
 ArmPkg/Include/Protocol/ArmScmiClockProtocol.h | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
index b7892bfd7771..9cd3a7ed232d 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
@@ -123,7 +123,7 @@ ClockGetClockAttributes (
   *MessageParams = ClockId;
 
   Cmd.ProtocolId = ScmiProtocolIdClock;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_ATTRIBUTES;
+  Cmd.MessageId  = ScmiMessageIdClockAttributes;
 
   PayloadLength = sizeof (ClockId);
 
@@ -204,7 +204,7 @@ ClockDescribeRates (
   }
 
   Cmd.ProtocolId = ScmiProtocolIdClock;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_DESCRIBE_RATES;
+  Cmd.MessageId  = ScmiMessageIdClockDescribeRates;
 
   *MessageParams++  = ClockId;
 
@@ -321,7 +321,7 @@ ClockRateGet (
   *MessageParams  = ClockId;
 
   Cmd.ProtocolId  = ScmiProtocolIdClock;
-  Cmd.MessageId   = SCMI_MESSAGE_ID_CLOCK_RATE_GET;
+  Cmd.MessageId   = ScmiMessageIdClockRateGet;
 
   PayloadLength = sizeof (ClockId);
 
@@ -375,7 +375,7 @@ ClockRateSet (
   ClockRateSetAttributes->Rate.High  = (UINT32)(Rate >> 32);
 
   Cmd.ProtocolId = ScmiProtocolIdClock;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_RATE_SET;
+  Cmd.MessageId  = ScmiMessageIdClockRateSet;
 
   PayloadLength = sizeof (CLOCK_RATE_SET_ATTRIBUTES);
 
@@ -422,7 +422,7 @@ ClockEnable (
   ClockConfigSetAttributes->Attributes = Enable ? BIT0 : 0;
 
   Cmd.ProtocolId = ScmiProtocolIdClock;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_CONFIG_SET;
+  Cmd.MessageId  = ScmiMessageIdClockConfigSet;
 
   PayloadLength = sizeof (CLOCK_CONFIG_SET_ATTRIBUTES);
 
diff --git a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
index 85b5b8d1e764..cd62f05a58fd 100644
--- a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
@@ -22,11 +22,11 @@ extern EFI_GUID gArmScmiClockProtocolGuid;
 
 // Message Type for clock management protocol.
 typedef enum {
-  SCMI_MESSAGE_ID_CLOCK_ATTRIBUTES = 0x3,
-  SCMI_MESSAGE_ID_CLOCK_DESCRIBE_RATES = 0x4,
-  SCMI_MESSAGE_ID_CLOCK_RATE_SET   = 0x5,
-  SCMI_MESSAGE_ID_CLOCK_RATE_GET   = 0x6,
-  SCMI_MESSAGE_ID_CLOCK_CONFIG_SET = 0x7
+  ScmiMessageIdClockAttributes= 0x3,
+  ScmiMessageIdClockDescribeRates = 0x4,
+  ScmiMessageIdClockRateSet   = 0x5,
+  ScmiMessageIdClockRateGet   = 0x6,
+  ScmiMessageIdClockConfigSet = 0x7
 } SCMI_MESSAGE_ID_CLOCK;
 
 typedef enum {
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72078): https://edk2.groups.io/g/devel/message/72078
Mute This Topic: https://groups.io/mt/80850104/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 23/26] ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_BASE

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3


Notes:
v3:
 - Import ScmiMessageIdBasexxx related changes from the patch
   'ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_CLOCK'. [Sami]

 ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c  | 12 ++--
 ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h | 10 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
index c84ce97f15ac..2c6206be9368 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
@@ -69,9 +69,9 @@ BaseGetTotalProtocols (
 
 /** Common function which returns vendor details.
 
-  @param[in] MessageId   SCMI_MESSAGE_ID_BASE_DISCOVER_VENDOR
+  @param[in] MessageId   ScmiMessageIdBaseDiscoverVendor
  OR
- SCMI_MESSAGE_ID_BASE_DISCOVER_SUB_VENDOR
+ ScmiMessageIdBaseDiscoverSubVendor
 
   @param[out] VendorIdentifier ASCII name of the vendor/subvendor.
 
@@ -133,7 +133,7 @@ BaseDiscoverVendor (
   )
 {
   return BaseDiscoverVendorDetails (
-   SCMI_MESSAGE_ID_BASE_DISCOVER_VENDOR,
+   ScmiMessageIdBaseDiscoverVendor,
VendorIdentifier
);
 }
@@ -156,7 +156,7 @@ BaseDiscoverSubVendor (
   )
 {
   return BaseDiscoverVendorDetails (
-   SCMI_MESSAGE_ID_BASE_DISCOVER_SUB_VENDOR,
+   ScmiMessageIdBaseDiscoverSubVendor,
VendorIdentifier
);
 }
@@ -184,7 +184,7 @@ BaseDiscoverImplVersion (
   UINT32PayloadLength;
 
   Cmd.ProtocolId = ScmiProtocolIdBase;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_BASE_DISCOVER_IMPLEMENTATION_VERSION;
+  Cmd.MessageId  = ScmiMessageIdBaseDiscoverImplementationVersion;
 
   PayloadLength = 0;
 
@@ -251,7 +251,7 @@ BaseDiscoverListProtocols (
   }
 
   Cmd.ProtocolId = ScmiProtocolIdBase;
-  Cmd.MessageId  = SCMI_MESSAGE_ID_BASE_DISCOVER_LIST_PROTOCOLS;
+  Cmd.MessageId  = ScmiMessageIdBaseDiscoverListProtocols;
 
   Skip = 0;
 
diff --git a/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
index 2f93ec92325e..73ad3e32a2f5 100644
--- a/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -158,10 +158,10 @@ typedef struct _SCMI_BASE_PROTOCOL {
 
 // SCMI Message IDs for Base protocol.
 typedef enum {
-  SCMI_MESSAGE_ID_BASE_DISCOVER_VENDOR  = 0x3,
-  SCMI_MESSAGE_ID_BASE_DISCOVER_SUB_VENDOR  = 0x4,
-  SCMI_MESSAGE_ID_BASE_DISCOVER_IMPLEMENTATION_VERSION  = 0x5,
-  SCMI_MESSAGE_ID_BASE_DISCOVER_LIST_PROTOCOLS  = 0x6
+  ScmiMessageIdBaseDiscoverVendor = 0x3,
+  ScmiMessageIdBaseDiscoverSubVendor  = 0x4,
+  ScmiMessageIdBaseDiscoverImplementationVersion  = 0x5,
+  ScmiMessageIdBaseDiscoverListProtocols  = 0x6
 } SCMI_MESSAGE_ID_BASE;
 
 #endif /* ARM_SCMI_BASE_PROTOCOL_H_ */
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72077): https://edk2.groups.io/g/devel/message/72077
Mute This Topic: https://groups.io/mt/80850103/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 22/26] ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/Scmi.c| 6 +++---
 ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/Scmi.c b/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
index a1bf1b95c052..3793c0663666 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
@@ -195,7 +195,7 @@ ScmiGetProtocolVersion (
 
   Status = ScmiProtocolDiscoveryCommon (
  ProtocolId,
- SCMI_MESSAGE_ID_PROTOCOL_VERSION,
+ ScmiMessageIdProtocolVersion,
  (UINT32**)&ProtocolVersion
  );
   if (EFI_ERROR (Status)) {
@@ -224,7 +224,7 @@ ScmiGetProtocolAttributes (
 {
   return ScmiProtocolDiscoveryCommon (
ProtocolId,
-   SCMI_MESSAGE_ID_PROTOCOL_ATTRIBUTES,
+   ScmiMessageIdProtocolAttributes,
ReturnValues
);
 }
@@ -246,7 +246,7 @@ ScmiGetProtocolMessageAttributes (
 {
   return ScmiProtocolDiscoveryCommon (
ProtocolId,
-   SCMI_MESSAGE_ID_PROTOCOL_MESSAGE_ATTRIBUTES,
+   ScmiMessageIdProtocolMessageAttributes,
ReturnValues
);
 }
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
index 118961dbe219..e56c9e0dc342 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
@@ -45,9 +45,9 @@ typedef enum {
 
 // SCMI message IDs common to all protocols.
 typedef enum {
-  SCMI_MESSAGE_ID_PROTOCOL_VERSION= 0x0,
-  SCMI_MESSAGE_ID_PROTOCOL_ATTRIBUTES = 0x1,
-  SCMI_MESSAGE_ID_PROTOCOL_MESSAGE_ATTRIBUTES = 0x2
+  ScmiMessageIdProtocolVersion   = 0x0,
+  ScmiMessageIdProtocolAttributes= 0x1,
+  ScmiMessageIdProtocolMessageAttributes = 0x2
 } SCMI_MESSAGE_ID;
 
 // Not defined in SCMI specification but will help to identify a message.
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72076): https://edk2.groups.io/g/devel/message/72076
Mute This Topic: https://groups.io/mt/80850101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 21/26] ArmPkg: Fix Ecc error 8005 for SCMI_STATUS

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/Scmi.c|  2 +-
 ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h | 22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/Scmi.c b/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
index 25f6cc3371af..a1bf1b95c052 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
@@ -123,7 +123,7 @@ ScmiCommandExecute (
 
   Response = (SCMI_MESSAGE_RESPONSE*)MtlGetChannelPayload (Channel);
 
-  if (Response->Status != SCMI_SUCCESS) {
+  if (Response->Status != ScmiSuccess) {
 DEBUG ((DEBUG_ERROR, "SCMI error: ProtocolId = 0x%x, MessageId = 0x%x, 
error = %d\n",
   Command->ProtocolId,
   Command->MessageId,
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
index 6de57a5c9514..118961dbe219 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
@@ -30,17 +30,17 @@ typedef enum {
 
 // SCMI response error codes.
 typedef enum {
-  SCMI_SUCCESS=  0,
-  SCMI_NOT_SUPPORTED  = -1,
-  SCMI_INVALID_PARAMETERS = -2,
-  SCMI_DENIED = -3,
-  SCMI_NOT_FOUND  = -4,
-  SCMI_OUT_OF_RANGE   = -5,
-  SCMI_BUSY   = -6,
-  SCMI_COMMS_ERROR= -7,
-  SCMI_GENERIC_ERROR  = -8,
-  SCMI_HARDWARE_ERROR = -9,
-  SCMI_PROTOCOL_ERROR = -10
+  ScmiSuccess   =  0,
+  ScmiNotSupported  = -1,
+  ScmiInvalidParameters = -2,
+  ScmiDenied= -3,
+  ScmiNotFound  = -4,
+  ScmiOutOfRange= -5,
+  ScmiBusy  = -6,
+  ScmiCommsError= -7,
+  ScmiGenericError  = -8,
+  ScmiHardwareError = -9,
+  ScmiProtocolError = -10
 } SCMI_STATUS;
 
 // SCMI message IDs common to all protocols.
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72075): https://edk2.groups.io/g/devel/message/72075
Mute This Topic: https://groups.io/mt/80850100/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 20/26] ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_TYPE

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/Scmi.c| 2 +-
 ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/Scmi.c b/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
index 847868a7749e..25f6cc3371af 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/Scmi.c
@@ -95,7 +95,7 @@ ScmiCommandExecute (
   // Fill in message header.
   MessageHeader = SCMI_MESSAGE_HEADER (
 Command->MessageId,
-SCMI_MESSAGE_TYPE_COMMAND,
+ScmiMessageTypeCommand,
 Command->ProtocolId
 );
 
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
index 5f1225f54cd9..6de57a5c9514 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
@@ -23,9 +23,9 @@ typedef enum {
 
 // SCMI message types.
 typedef enum {
-  SCMI_MESSAGE_TYPE_COMMAND  = 0,
-  SCMI_MESSAGE_TYPE_DELAYED_RESPONSE = 2, // Skipping 1 is deliberate.
-  SCMI_MESSAGE_TYPE_NOTIFICATION = 3
+  ScmiMessageTypeCommand = 0,
+  ScmiMessageTypeDelayedResponse = 2, // Skipping 1 is deliberate.
+  ScmiMessageTypeNotification= 3
 } SCMI_MESSAGE_TYPE;
 
 // SCMI response error codes.
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72074): https://edk2.groups.io/g/devel/message/72074
Mute This Topic: https://groups.io/mt/80850099/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 19/26] ArmPkg: Fix Ecc error 8005 for SCMI_PROTOCOL_ID

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c   | 12 ++--
 ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c  | 14 +++---
 ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c| 10 +-
 .../ArmScmiDxe/ScmiPerformanceProtocol.c   | 18 +-
 ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h| 14 +++---
 5 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
index d89587f9edf3..c84ce97f15ac 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -34,7 +34,7 @@ BaseGetVersion (
   OUT UINT32  *Version
   )
 {
-  return ScmiGetProtocolVersion (SCMI_PROTOCOL_ID_BASE, Version);
+  return ScmiGetProtocolVersion (ScmiProtocolIdBase, Version);
 }
 
 /** Return total number of SCMI protocols supported by the SCP firmware.
@@ -57,7 +57,7 @@ BaseGetTotalProtocols (
   EFI_STATUS  Status;
   UINT32  *ReturnValues;
 
-  Status = ScmiGetProtocolAttributes (SCMI_PROTOCOL_ID_BASE, &ReturnValues);
+  Status = ScmiGetProtocolAttributes (ScmiProtocolIdBase, &ReturnValues);
   if (EFI_ERROR (Status)) {
 return Status;
   }
@@ -91,7 +91,7 @@ BaseDiscoverVendorDetails (
   SCMI_COMMAND  Cmd;
   UINT32PayloadLength;
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_BASE;
+  Cmd.ProtocolId = ScmiProtocolIdBase;
   Cmd.MessageId  = MessageId;
 
   PayloadLength = 0;
@@ -183,7 +183,7 @@ BaseDiscoverImplVersion (
   SCMI_COMMAND  Cmd;
   UINT32PayloadLength;
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_BASE;
+  Cmd.ProtocolId = ScmiProtocolIdBase;
   Cmd.MessageId  = SCMI_MESSAGE_ID_BASE_DISCOVER_IMPLEMENTATION_VERSION;
 
   PayloadLength = 0;
@@ -250,7 +250,7 @@ BaseDiscoverListProtocols (
 return EFI_BUFFER_TOO_SMALL;
   }
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_BASE;
+  Cmd.ProtocolId = ScmiProtocolIdBase;
   Cmd.MessageId  = SCMI_MESSAGE_ID_BASE_DISCOVER_LIST_PROTOCOLS;
 
   Skip = 0;
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
index 5c06e31bda22..b7892bfd7771 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
@@ -52,7 +52,7 @@ ClockGetVersion (
   OUT UINT32   *Version
   )
 {
-  return ScmiGetProtocolVersion (SCMI_PROTOCOL_ID_CLOCK, Version);
+  return ScmiGetProtocolVersion (ScmiProtocolIdClock, Version);
 }
 
 /** Return total number of clock devices supported by the clock management
@@ -76,7 +76,7 @@ ClockGetTotalClocks (
   EFI_STATUS  Status;
   UINT32 *ReturnValues;
 
-  Status = ScmiGetProtocolAttributes (SCMI_PROTOCOL_ID_CLOCK, &ReturnValues);
+  Status = ScmiGetProtocolAttributes (ScmiProtocolIdClock, &ReturnValues);
   if (EFI_ERROR (Status)) {
 return Status;
   }
@@ -122,7 +122,7 @@ ClockGetClockAttributes (
 
   *MessageParams = ClockId;
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_CLOCK;
+  Cmd.ProtocolId = ScmiProtocolIdClock;
   Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_ATTRIBUTES;
 
   PayloadLength = sizeof (ClockId);
@@ -203,7 +203,7 @@ ClockDescribeRates (
 return Status;
   }
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_CLOCK;
+  Cmd.ProtocolId = ScmiProtocolIdClock;
   Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_DESCRIBE_RATES;
 
   *MessageParams++  = ClockId;
@@ -320,7 +320,7 @@ ClockRateGet (
   // Fill arguments for clock protocol command.
   *MessageParams  = ClockId;
 
-  Cmd.ProtocolId  = SCMI_PROTOCOL_ID_CLOCK;
+  Cmd.ProtocolId  = ScmiProtocolIdClock;
   Cmd.MessageId   = SCMI_MESSAGE_ID_CLOCK_RATE_GET;
 
   PayloadLength = sizeof (ClockId);
@@ -374,7 +374,7 @@ ClockRateSet (
   ClockRateSetAttributes->Rate.Low   = (UINT32)Rate;
   ClockRateSetAttributes->Rate.High  = (UINT32)(Rate >> 32);
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_CLOCK;
+  Cmd.ProtocolId = ScmiProtocolIdClock;
   Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_RATE_SET;
 
   PayloadLength = sizeof (CLOCK_RATE_SET_ATTRIBUTES);
@@ -421,7 +421,7 @@ ClockEnable (
   ClockConfigSetAttributes->ClockId= ClockId;
   ClockConfigSetAttributes->Attributes = Enable ? BIT0 : 0;
 
-  Cmd.ProtocolId = SCMI_PROTOCOL_ID_CLOCK;
+  Cmd.ProtocolId = ScmiProtocolIdClock;
   Cmd.MessageId  = SCMI_MESSAGE_ID_CLOCK_CONFIG_SET;
 
   PayloadLength = sizeof (CLOCK_CONFIG_SET_ATTRIBUTES);
diff --git a/ArmPkg/Dri

[edk2-devel] [PATCH v3 18/26] ArmPkg: Fix Ecc error 8005/8007 in ArmDisassemblerLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
8005:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'

8007:
There should be no use of short (single character) variable names

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 .../ArmDisassemblerLib/ArmDisassembler.c  | 159 +-
 .../ArmDisassemblerLib/ThumbDisassembler.c| 158 -
 2 files changed, 163 insertions(+), 154 deletions(-)

diff --git a/ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c 
b/ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c
index e67e13a50ace..03a9f1fbe2e5 100644
--- a/ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c
+++ b/ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c
@@ -71,7 +71,7 @@ CHAR8 *gLdmStack[] = {
 
 
 #define SIGN(_U)  ((_U) ? "" : "-")
-#define WRITE(_W) ((_W) ? "!" : "")
+#define WRITE(_Write) ((_Write) ? "!" : "")
 #define BYTE(_B)  ((_B) ? "B":"")
 #define USER(_B)  ((_B) ? "^" : "")
 
@@ -159,23 +159,24 @@ DisassembleArmInstruction (
   )
 {
   UINT32OpCode;
-  CHAR8 *Type, *Root;
-  BOOLEAN   I, P, U, B, W, L, S, H;
+  CHAR8 *Type;
+  CHAR8 *Root;
+  BOOLEAN   Imm, Pre, Up, WriteBack, Write, Load, Sign, Half;
   UINT32Rn, Rd, Rm;
-  UINT32imode, offset_8, offset_12;
+  UINT32IMod, Offset8, Offset12;
   UINT32Index;
-  UINT32shift_imm, shift;
+  UINT32ShiftImm, Shift;
 
   OpCode = **OpCodePtr;
 
-  I = (OpCode & BIT25) == BIT25;
-  P = (OpCode & BIT24) == BIT24;
-  U = (OpCode & BIT23) == BIT23;
-  B = (OpCode & BIT22) == BIT22;  // Also called S
-  W = (OpCode & BIT21) == BIT21;
-  L = (OpCode & BIT20) == BIT20;
-  S = (OpCode & BIT6) == BIT6;
-  H = (OpCode & BIT5) == BIT5;
+  Imm = (OpCode & BIT25) == BIT25; // I
+  Pre = (OpCode & BIT24) == BIT24; // P
+  Up = (OpCode & BIT23) == BIT23; // U
+  WriteBack = (OpCode & BIT22) == BIT22; // B, also called S
+  Write = (OpCode & BIT21) == BIT21; // W
+  Load = (OpCode & BIT20) == BIT20; // L
+  Sign = (OpCode & BIT6) == BIT6; // S
+  Half = (OpCode & BIT5) == BIT5; // H
   Rn = (OpCode >> 16) & 0xf;
   Rd = (OpCode >> 12) & 0xf;
   Rm = (OpCode & 0xf);
@@ -189,7 +190,7 @@ DisassembleArmInstruction (
 
   // LDREX, STREX
   if ((OpCode  & 0x0fe000f0) == 0x01800090) {
-if (L) {
+if (Load) {
   // A4.1.27  LDREX{} , []
   AsciiSPrint (Buf, Size, "LDREX%a %a, [%a]", COND (OpCode), gReg[Rd], 
gReg[Rn]);
 } else {
@@ -201,89 +202,89 @@ DisassembleArmInstruction (
 
   // LDM/STM
   if ((OpCode  & 0x0e00) == 0x0800) {
-if (L) {
+if (Load) {
   // A4.1.20 LDM{} {!}, 
   // A4.1.21 LDM{} , ^
   // A4.1.22 LDM{} {!}, ^
-  AsciiSPrint (Buf, Size, "LDM%a%a, %a%a, %a", COND (OpCode), LDM_EXT (Rn 
,(OpCode >> 23) & 3), gReg[Rn], WRITE (W), MRegList (OpCode), USER (B));
+  AsciiSPrint (Buf, Size, "LDM%a%a, %a%a, %a", COND (OpCode), LDM_EXT (Rn 
,(OpCode >> 23) & 3), gReg[Rn], WRITE (Write), MRegList (OpCode), USER 
(WriteBack));
 } else {
   // A4.1.97 STM{} {!}, 
   // A4.1.98 STM{} , ^
-  AsciiSPrint (Buf, Size, "STM%a%a, %a%a, %a", COND (OpCode), LDM_EXT (Rn 
,(OpCode >> 23) & 3), gReg[Rn], WRITE (W), MRegList (OpCode), USER (B));
+  AsciiSPrint (Buf, Size, "STM%a%a, %a%a, %a", COND (OpCode), LDM_EXT (Rn 
,(OpCode >> 23) & 3), gReg[Rn], WRITE (Write), MRegList (OpCode), USER 
(WriteBack));
 }
 return;
   }
 
   // LDR/STR Address Mode 2
   if ( ((OpCode  & 0x0c00) == 0x0400) || ((OpCode & 0xfd70f000 ) == 
0xf550f000) ) {
-offset_12 = OpCode & 0xfff;
+Offset12 = OpCode & 0xfff;
 if ((OpCode & 0xfd70f000 ) == 0xf550f000) {
   Index = AsciiSPrint (Buf, Size, "PLD");
 } else {
-  Index = AsciiSPrint (Buf, Size, "%a%a%a%a %a, ", L ? "LDR" : "STR", COND 
(OpCode), BYTE (B), (!(P) && W) ? "T":"", gReg[Rd]);
+  Index = AsciiSPrint (Buf, Size, "%a%a%a%a %a, ", Load ? "LDR" : "STR", 
COND (OpCode), BYTE (WriteBack), (!(Pre) && Write) ? "T":"", gReg[Rd]);
 }
-if (P) {
-  if (!I) {
+if (Pre) {
+  if (!Imm) {
 // A5.2.2 [, #+/-]
 // A5.2.5 [, #+/-]
-AsciiSPrint (&Buf[Index], Size - Index, "[%a, #%a0x%x]%a", gReg[Rn], 
SIGN (U), offset_12, WRITE (W));
+AsciiSPrint (&Buf[Index], Size - Index, "[%a, #%a0x%x]%a", gReg[Rn], 
SIGN (Up), Offset12, WRITE (Write));
   } else if ((OpCode & 0x03000ff0) == 0x0300) {
 // A5.2.3 [, +/-]
 // A5.2.6 [, +/-]!
-AsciiSPrint (&Buf[Index], Size - Index, "[%a, #%a%a]%a", gReg[Rn], 
SIGN (U), WRITE (W));
+AsciiSPrint (&Buf[Index], Size - Index, "[%a, #%a%a]%a", gReg[Rn], 
SIGN (Up), WRITE (Write));
   } else {
 // A5.2.4 [, +/-, LSL #]
 // A5.2.7 [, +/-, LSL #]!
-shift_

[edk2-devel] [PATCH v3 17/26] ArmPkg: Fix Ecc error 7008 for OPTEE_MESSAGE_PARAM

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Complex types should be typedef-ed

The error is due to the a nested structure declaration.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Include/Library/OpteeLib.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/Include/Library/OpteeLib.h 
b/ArmPkg/Include/Library/OpteeLib.h
index d71636143373..8ceab117d132 100644
--- a/ArmPkg/Include/Library/OpteeLib.h
+++ b/ArmPkg/Include/Library/OpteeLib.h
@@ -2,6 +2,7 @@
   OP-TEE specific header file.
 
   Copyright (c) 2018, Linaro Ltd. All rights reserved.
+  Copyright (c) 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -45,12 +46,14 @@ typedef struct {
   UINT64C;
 } OPTEE_MESSAGE_PARAM_VALUE;
 
+typedef union {
+  OPTEE_MESSAGE_PARAM_MEMORY   Memory;
+  OPTEE_MESSAGE_PARAM_VALUEValue;
+} OPTEE_MESSAGE_PARAM_UNION;
+
 typedef struct {
   UINT64 Attribute;
-  union {
-OPTEE_MESSAGE_PARAM_MEMORY   Memory;
-OPTEE_MESSAGE_PARAM_VALUEValue;
-  } Union;
+  OPTEE_MESSAGE_PARAM_UNION Union;
 } OPTEE_MESSAGE_PARAM;
 
 #define OPTEE_MAX_CALL_PARAMS   4
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72071): https://edk2.groups.io/g/devel/message/72071
Mute This Topic: https://groups.io/mt/80850095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 16/26] ArmPkg: Fix Ecc error 7008 for SCMI_CLOCK_RATE

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Complex types should be typedef-ed

The error is due to the a nested structure declaration.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c  | 12 
 ArmPkg/Include/Protocol/ArmScmiClockProtocol.h | 14 ++
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
index c66c414385dd..5c06e31bda22 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
@@ -255,22 +255,26 @@ ClockDescribeRates (
   for (RateNo = 0; RateNo < NUM_RATES (DescribeRates->NumRatesFlags); 
RateNo++) {
 Rate = &DescribeRates->Rates[RateOffset++];
 // Non-linear discrete rates.
-RateArray[RateIndex++].Rate = ConvertTo64Bit (Rate->Low, Rate->High);
+RateArray[RateIndex++].DiscreteRate.Rate =
+  ConvertTo64Bit (Rate->Low, Rate->High);
   }
 } else {
   for (RateNo = 0; RateNo < NUM_RATES (DescribeRates->NumRatesFlags); 
RateNo++) {
 // Linear clock rates from minimum to maximum in steps
 // Minimum clock rate.
 Rate = &DescribeRates->Rates[RateOffset++];
-RateArray[RateIndex].Min = ConvertTo64Bit (Rate->Low, Rate->High);
+RateArray[RateIndex].ContinuousRate.Min =
+  ConvertTo64Bit (Rate->Low, Rate->High);
 
 Rate = &DescribeRates->Rates[RateOffset++];
 // Maximum clock rate.
-RateArray[RateIndex].Max = ConvertTo64Bit (Rate->Low, Rate->High);
+RateArray[RateIndex].ContinuousRate.Max =
+  ConvertTo64Bit (Rate->Low, Rate->High);
 
 Rate = &DescribeRates->Rates[RateOffset++];
 // Step.
-RateArray[RateIndex++].Step = ConvertTo64Bit (Rate->Low, Rate->High);
+RateArray[RateIndex++].ContinuousRate.Step =
+  ConvertTo64Bit (Rate->Low, Rate->High);
   }
 }
   } while (NUM_REMAIN_RATES (DescribeRates->NumRatesFlags) != 0);
diff --git a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
index b4d970dee3e2..85b5b8d1e764 100644
--- a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -57,12 +57,18 @@ typedef enum {
either Rate or Min/Max/Step triplet is valid.
 */
 typedef struct {
-  union {
   UINT64 Min;
-  UINT64 Rate;
-  };
   UINT64 Max;
   UINT64 Step;
+} SCMI_CLOCK_RATE_CONTINUOUS;
+
+typedef struct {
+  UINT64 Rate;
+} SCMI_CLOCK_RATE_DISCRETE;
+
+typedef union {
+  SCMI_CLOCK_RATE_CONTINUOUS ContinuousRate;
+  SCMI_CLOCK_RATE_DISCRETE DiscreteRate;
 } SCMI_CLOCK_RATE;
 
 #pragma pack()
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72070): https://edk2.groups.io/g/devel/message/72070
Mute This Topic: https://groups.io/mt/80850094/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 15/26] ArmPkg: Rename include guard in ArmGicLib.h

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

Edk2 coding standard states that:
"Names starting with one or two underscores, such as
_MACRO_GUARD_FILE_NAME_H_, must not be used."

Ref:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/
5_source_files/53_include_files#
5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Include/Library/ArmGicLib.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/Include/Library/ArmGicLib.h 
b/ArmPkg/Include/Library/ArmGicLib.h
index 7bcfc001115b..b4c320be119b 100644
--- a/ArmPkg/Include/Library/ArmGicLib.h
+++ b/ArmPkg/Include/Library/ArmGicLib.h
@@ -1,13 +1,13 @@
 /** @file
 *
-*  Copyright (c) 2011-2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2021, Arm Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
 **/
 
-#ifndef __ARMGIC_H
-#define __ARMGIC_H
+#ifndef ARMGIC_H_
+#define ARMGIC_H_
 
 #include 
 
@@ -333,4 +333,4 @@ ArmGicV3SetPriorityMask (
   IN UINTN  Priority
   );
 
-#endif
+#endif // ARMGIC_H_
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72069): https://edk2.groups.io/g/devel/message/72069
Mute This Topic: https://groups.io/mt/80850093/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 14/26] ArmPkg: Fix Ecc error 6001 in ArmSoftFloatLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
All include file contents should be guarded by
a #ifndef statement.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Library/ArmSoftFloatLib/platform.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ArmPkg/Library/ArmSoftFloatLib/platform.h 
b/ArmPkg/Library/ArmSoftFloatLib/platform.h
index 07800a9d5b79..fddf9de04d52 100644
--- a/ArmPkg/Library/ArmSoftFloatLib/platform.h
+++ b/ArmPkg/Library/ArmSoftFloatLib/platform.h
@@ -1,11 +1,17 @@
 /*
  * Copyright (c) 2019, Linaro Limited
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
  *
  * SPDX-License-Identifier: BSD-2-Clause-Patent
  */
 
+#ifndef ARM_SOFT_FLOAT_LIB_H_
+#define ARM_SOFT_FLOAT_LIB_H_
+
 #define LITTLEENDIAN 1
 #define INLINE static inline
 #define SOFTFLOAT_BUILTIN_CLZ 1
 #define SOFTFLOAT_FAST_INT64
 #include "opts-GCC.h"
+
+#endif // ARM_SOFT_FLOAT_LIB_H_
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72068): https://edk2.groups.io/g/devel/message/72068
Mute This Topic: https://groups.io/mt/80850091/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 13/26] ArmPkg: Fix Ecc error 6001 in MmCommunicationDxe

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
All include file contents should be guarded by
a #ifndef statement.

This patch replaces a "#if !defined [...]" statement
by a "#ifndef [...]" statement, preventing Ecc to
throw an error.

Edk2 coding standard stating that:
"Names starting with one or two underscores, such as
_MACRO_GUARD_FILE_NAME_H_, must not be used."
the include guard is also updated.

Ref:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/
5_source_files/53_include_files#
5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
index fcc346ba7e3e..32753947e1cb 100644
--- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
@@ -1,13 +1,13 @@
 /** @file
 
-  Copyright (c) 2016-2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
-#if !defined _MM_COMMUNICATE_H_
-#define _MM_COMMUNICATE_H_
+#ifndef MM_COMMUNICATE_H_
+#define MM_COMMUNICATE_H_
 
 #define MM_MAJOR_VER_MASK0xEFFF
 #define MM_MINOR_VER_MASK0x
@@ -19,4 +19,4 @@
 #define MM_CALLER_MAJOR_VER  0x1UL
 #define MM_CALLER_MINOR_VER  0x0
 
-#endif /* _MM_COMMUNICATE_H_ */
+#endif /* MM_COMMUNICATE_H_ */
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72067): https://edk2.groups.io/g/devel/message/72067
Mute This Topic: https://groups.io/mt/80850090/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 12/26] ArmPkg: Fix Ecc error 5003 in ArmExceptionLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Function name should be left justified,
followed by the beginning of the parameter list,
with the closing parenthesis on its own line,
indented two spaces

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c | 4 +++-
 ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c | 5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c 
b/ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c
index 514f80a2d47a..fcf3dd16443e 100644
--- a/ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c
+++ b/ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c
@@ -2,6 +2,7 @@
 *  Exception Handling support specific for AArch64
 *
 *  Copyright (c) 2016 HP Development Company, L.P.
+*  Copyright (c) 2021, Arm Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -27,7 +28,8 @@ RegisterEl0Stack (
   IN  VOID*Stack
   );
 
-RETURN_STATUS ArchVectorConfig(
+RETURN_STATUS
+ArchVectorConfig (
   IN  UINTN   VectorBaseAddress
   )
 {
diff --git a/ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c 
b/ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c
index 36c9f3f92616..40857c7f1faf 100644
--- a/ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c
+++ b/ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c
@@ -2,7 +2,7 @@
 *  Exception handling support specific for ARM
 *
 * Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-* Copyright (c) 2014, ARM Limited. All rights reserved.
+* Copyright (c) 2014 - 2021, Arm Limited. All rights reserved.
 * Copyright (c) 2016 HP Development Company, L.P.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -26,7 +26,8 @@ PHYSICAL_ADDRESSgExceptionVectorAlignmentMask = 
ARM_VECTOR_TABLE_ALIGNME
 // NOTE: This code assumes vectors are ARM and not Thumb code
 UINTN   gDebuggerNoHandlerValue = 0xEAFE;
 
-RETURN_STATUS ArchVectorConfig(
+RETURN_STATUS
+ArchVectorConfig (
   IN  UINTN   VectorBaseAddress
   )
 {
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72066): https://edk2.groups.io/g/devel/message/72066
Mute This Topic: https://groups.io/mt/80850089/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 11/26] ArmPkg: Remove ArmGic/ArmGicSecLib.c

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

Commit: 142fa386eb907df55c239311cd5fa2d40f5007dd
removes the ArmGicSecLib. The file ArmGic/ArmGicSecLib.c
was exclusively used by this library. Thus, this file should
also be removed.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmGic/ArmGicSecLib.c | 58 
 1 file changed, 58 deletions(-)
 delete mode 100644 ArmPkg/Drivers/ArmGic/ArmGicSecLib.c

diff --git a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.c 
b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.c
deleted file mode 100644
index 4af98bb6ec93..
--- a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/** @file
-*
-*  Copyright (c) 2011-2014, ARM Limited. All rights reserved.
-*
-*  SPDX-License-Identifier: BSD-2-Clause-Patent
-*
-**/
-
-#include 
-#include 
-#include 
-#include 
-
-/*
- * This function configures the interrupts set by the mask to be secure.
- *
- */
-VOID
-EFIAPI
-ArmGicSetSecureInterrupts (
-  IN  UINTN GicDistributorBase,
-  IN  UINTN*GicSecureInterruptMask,
-  IN  UINTN GicSecureInterruptMaskSize
-  )
-{
-  UINTN  Index;
-  UINT32 InterruptStatus;
-
-  // We must not have more interrupts defined by the mask than the number of 
available interrupts
-  ASSERT(GicSecureInterruptMaskSize <= (ArmGicGetMaxNumInterrupts 
(GicDistributorBase) / 32));
-
-  // Set all the interrupts defined by the mask as Secure
-  for (Index = 0; Index < GicSecureInterruptMaskSize; Index++) {
-InterruptStatus = MmioRead32 (GicDistributorBase + ARM_GIC_ICDISR + (Index 
* 4));
-MmioWrite32 (GicDistributorBase + ARM_GIC_ICDISR + (Index * 4), 
InterruptStatus & (~GicSecureInterruptMask[Index]));
-  }
-}
-
-VOID
-EFIAPI
-ArmGicEnableDistributor (
-  IN  INTN  GicDistributorBase
-  )
-{
-  // Turn on the GIC distributor
-  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 1);
-}
-
-VOID
-EFIAPI
-ArmGicSetupNonSecure (
-  IN  UINTN MpId,
-  IN  INTN  GicDistributorBase,
-  IN  INTN  GicInterruptInterfaceBase
-  )
-{
-  ArmGicV2SetupNonSecure (MpId, GicDistributorBase, GicInterruptInterfaceBase);
-}
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72065): https://edk2.groups.io/g/devel/message/72065
Mute This Topic: https://groups.io/mt/80850086/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 10/26] ArmPkg: Fix Ecc error 10014 in SemihostLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
No used module files found

The source files
[ArmPkg/Library/SemihostLib/SemihostPrivate.h]
is existing in module
ArmPkg/Library/SemihostLib/SemihostLib.inf
but is not described in the INF file.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Library/SemihostLib/SemihostLib.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Library/SemihostLib/SemihostLib.inf 
b/ArmPkg/Library/SemihostLib/SemihostLib.inf
index a46618d30eef..2a4409f6573b 100644
--- a/ArmPkg/Library/SemihostLib/SemihostLib.inf
+++ b/ArmPkg/Library/SemihostLib/SemihostLib.inf
@@ -2,7 +2,7 @@
 # Semihosting JTAG lib
 #
 # Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
-# Copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
+# Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -25,6 +25,7 @@ [Defines]
 #
 [Sources.common]
   SemihostLib.c
+  SemihostPrivate.h
 
 [Sources.ARM]
   Arm/GccSemihost.S | GCC
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72064): https://edk2.groups.io/g/devel/message/72064
Mute This Topic: https://groups.io/mt/80850083/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 09/26] ArmPkg: Fix Ecc error 10014 in MmCommunicationDxe

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
No used module files found

The source files
[ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h]
is existing in module
ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
but is not described in the INF file.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
index 2465fb77c58e..05b6de73ff34 100644
--- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
@@ -2,7 +2,7 @@
 #
 #  DXE MM Communicate driver
 #
-#  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
+#  Copyright (c) 2016 - 2021, Arm Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -24,6 +24,7 @@ [Defines]
 #
 
 [Sources.AARCH64]
+  MmCommunicate.h
   MmCommunication.c
 
 [Packages]
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72063): https://edk2.groups.io/g/devel/message/72063
Mute This Topic: https://groups.io/mt/80850079/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 08/26] ArmPkg: Fix Ecc error 10014 in GenericWatchdogDxe

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
No used module files found

The source files
[ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdog.h]
is existing in module
ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
but is not described in the INF file.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf 
b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
index d725a2c85839..7dbd30783892 100644
--- a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+++ b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2013-2017, ARM Limited. All rights reserved.
+#  Copyright (c) 2013-2021, Arm Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -13,6 +13,7 @@ [Defines]
   ENTRY_POINT= GenericWatchdogEntry
 
 [Sources.common]
+  GenericWatchdog.h
   GenericWatchdogDxe.c
 
 [Packages]
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72062): https://edk2.groups.io/g/devel/message/72062
Mute This Topic: https://groups.io/mt/80850077/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 06/26] ArmPkg: Fix Ecc error 10016 in StandaloneMmMmuLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Module file has FILE_GUID collision with other
module file

The two .inf files with clashing GUID are:
ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf

As ArmMmuBaseLib.inf is older than ArmMmuStandaloneMmLib.inf,
it has precedence.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf 
b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
index 85973687f5ad..0a147fff18c0 100644
--- a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
+++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
@@ -1,6 +1,6 @@
 #/** @file
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -10,7 +10,7 @@
 [Defines]
   INF_VERSION= 0x0001001A
   BASE_NAME  = ArmMmuStandaloneMmCoreLib
-  FILE_GUID  = da8f0232-fb14-42f0-922c-63104d2c70bd
+  FILE_GUID  = 44a741c2-655f-41fc-b066-179f5a9aa78a
   MODULE_TYPE= MM_CORE_STANDALONE
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = StandaloneMmMmuLib
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72060): https://edk2.groups.io/g/devel/message/72060
Mute This Topic: https://groups.io/mt/80850074/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 07/26] ArmPkg: Fix Ecc error 10014 in ArmScmiDxe

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
No used module files found

The source files
[ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h]
[ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h]
[ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.h]
[ArmPkg/Drivers/ArmScmiDxe/ArmScmiBaseProtocolPrivate.h]
[ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h]
are existing in module
ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
but are not described in INF the file.

The patch also re-orders the files in the
[Sources.common] section.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf 
b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
index 6cd3aa1c82ec..fc5f841c2b7c 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
+++ b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
@@ -1,6 +1,6 @@
 #/** @file
 #
-#  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
+#  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -18,11 +18,16 @@ [Defines]
   ENTRY_POINT= ArmScmiDxeEntryPoint
 
 [Sources.common]
-  Scmi.c
+  ArmScmiBaseProtocolPrivate.h
+  ArmScmiClockProtocolPrivate.h
+  ArmScmiPerformanceProtocolPrivate.h
   ScmiBaseProtocol.c
+  Scmi.c
   ScmiClockProtocol.c
   ScmiDxe.c
+  ScmiDxe.h
   ScmiPerformanceProtocol.c
+  ScmiPrivate.h
 
 [Packages]
   ArmPkg/ArmPkg.dec
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72061): https://edk2.groups.io/g/devel/message/72061
Mute This Topic: https://groups.io/mt/80850075/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 04/26] ArmPkg: Fix Ecc error 9005 in CpuDxe

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Only Doxygen commands '@bug', '@todo', '@example', '@file',
'@attention', '@param', '@post', '@pre', '@retval', '@return',
'@sa', '@since', '@test', '@note', '@par', '@endcode', '@code',
'@{', '@}' are allowed to mark the code

This patch removes the ":" character following the "@param"
doxygen command.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Drivers/CpuDxe/CpuMpCore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/CpuMpCore.c 
b/ArmPkg/Drivers/CpuDxe/CpuMpCore.c
index d16ae3979207..8a9e8c2fa3a2 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuMpCore.c
+++ b/ArmPkg/Drivers/CpuDxe/CpuMpCore.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2021, Arm Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -32,7 +32,7 @@ ARM_PROCESSOR_TABLE mArmProcessorTableTemplate = {
 };
 
 /** Publish ARM Processor Data table in UEFI SYSTEM Table.
- * @param:  HobStart   Pointer to the beginning of the HOB List 
from PEI.
+ * @param  HobStart   Pointer to the beginning of the HOB List 
from PEI.
  *
  * Description : This function iterates through HOB list and finds ARM 
processor Table Entry HOB.
  *   If  the ARM processor Table Entry HOB is found, the HOB data 
is copied to run-time memory
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72058): https://edk2.groups.io/g/devel/message/72058
Mute This Topic: https://groups.io/mt/80850071/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 05/26] ArmPkg: Fix Ecc error 10006 in ArmPkg.dsc

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
There should be no unnecessary inclusion of library
classes in the INF file

This comes with the additional information:
The Library Class [BootLogoLib]
is not used in any platform
The Library Class [DxeServicesLib]
is not used in any platform
The Library Class [UefiBootManagerLib]
is not used in any platform
The Library Class [PeCoffExtraActionLib]
is not used in any platform

ArmPkg/ArmPkg.dsc builds the modules requiring thses libraries,
but doesn't build the required libraries. This patch adds
the missing libraries to the [LibraryClasses.common] section.

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/ArmPkg.dsc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 7194eb2d3c44..10df4963ca36 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -2,7 +2,7 @@
 # ARM processor package.
 #
 # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved.
-# Copyright (c) 2011 - 2018, ARM Ltd. All rights reserved.
+# Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.
 # Copyright (c) 2016, Linaro Ltd. All rights reserved.
 # Copyright (c) Microsoft Corporation.
 #
@@ -35,14 +35,17 @@ [PcdsFixedAtBuild]
 [LibraryClasses.common]
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
+  
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
   
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
   UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
@@ -50,6 +53,7 @@ [LibraryClasses.common]
   
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+  
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
 
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72059): https://edk2.groups.io/g/devel/message/72059
Mute This Topic: https://groups.io/mt/80850072/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 01/26] ArmPkg: Fix Ecc error 8001 in Chipset

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Only capital letters are allowed to be used
for #define declarations

Edk2 coding standard stating that:
"Names starting with one or two underscores, such as
_MACRO_GUARD_FILE_NAME_H_, must not be used."
the include guard of ArmCortexA5x.h is also updated.

Ref:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/
5_source_files/53_include_files#
5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3


Notes:
v2:
 - Only use one trailing underscore for the
   ARM_CORTEX_A5x_H__ include guard. [Sami]
 - 2 patches had the same name and fixed the same
   Ecc error in V1. They are merged in V2. [Pierre]

 ArmPkg/Include/Chipset/AArch64.h | 12 ++--
 ArmPkg/Include/Chipset/AArch64Mmu.h  |  4 ++--
 ArmPkg/Include/Chipset/ArmCortexA5x.h|  8 
 ArmPkg/Include/Chipset/ArmV7.h   |  4 ++--
 .../ArmExceptionLib/AArch64/ExceptionSupport.S   | 10 +-
 ArmPlatformPkg/PrePeiCore/AArch64/Exception.S| 10 +-
 6 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/ArmPkg/Include/Chipset/AArch64.h b/ArmPkg/Include/Chipset/AArch64.h
index 7c2b592f92ee..09d4cfe28da7 100644
--- a/ArmPkg/Include/Chipset/AArch64.h
+++ b/ArmPkg/Include/Chipset/AArch64.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-  Copyright (c) 2011 - 2017, ARM Ltd. All rights reserved.
+  Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -39,7 +39,7 @@
 // MIDR - Main ID Register definitions
 #define ARM_CPU_TYPE_SHIFT  4
 #define ARM_CPU_TYPE_MASK   0xFFF
-#define ARM_CPU_TYPE_AEMv8  0xD0F
+#define ARM_CPU_TYPE_AEMV8  0xD0F
 #define ARM_CPU_TYPE_A530xD03
 #define ARM_CPU_TYPE_A570xD07
 #define ARM_CPU_TYPE_A720xD08
@@ -97,10 +97,10 @@
 #define ARM_VECTOR_CUR_SP0_FIQ  0x100
 #define ARM_VECTOR_CUR_SP0_SERR 0x180
 
-#define ARM_VECTOR_CUR_SPx_SYNC 0x200
-#define ARM_VECTOR_CUR_SPx_IRQ  0x280
-#define ARM_VECTOR_CUR_SPx_FIQ  0x300
-#define ARM_VECTOR_CUR_SPx_SERR 0x380
+#define ARM_VECTOR_CUR_SPX_SYNC 0x200
+#define ARM_VECTOR_CUR_SPX_IRQ  0x280
+#define ARM_VECTOR_CUR_SPX_FIQ  0x300
+#define ARM_VECTOR_CUR_SPX_SERR 0x380
 
 #define ARM_VECTOR_LOW_A64_SYNC 0x400
 #define ARM_VECTOR_LOW_A64_IRQ  0x480
diff --git a/ArmPkg/Include/Chipset/AArch64Mmu.h 
b/ArmPkg/Include/Chipset/AArch64Mmu.h
index 606fe7420d67..6c7ada16b18a 100644
--- a/ArmPkg/Include/Chipset/AArch64Mmu.h
+++ b/ArmPkg/Include/Chipset/AArch64Mmu.h
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2021, Arm Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -190,7 +190,7 @@
 
 // The value written to the T*SZ fields are defined as 2^(64-T*SZ). So a 39Bit
 // Virtual address range for 512GB of virtual space sets T*SZ to 25
-#define INPUT_ADDRESS_SIZE_TO_TxSZ(a)(64 - a)
+#define INPUT_ADDRESS_SIZE_TO_TXSZ(a)(64 - a)
 
 // Uses LPAE Page Table format
 
diff --git a/ArmPkg/Include/Chipset/ArmCortexA5x.h 
b/ArmPkg/Include/Chipset/ArmCortexA5x.h
index 847a6e00430b..e597eee947cf 100644
--- a/ArmPkg/Include/Chipset/ArmCortexA5x.h
+++ b/ArmPkg/Include/Chipset/ArmCortexA5x.h
@@ -1,13 +1,13 @@
 /** @file
 
-  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
+  Copyright (c) 2012 - 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
-#ifndef __ARM_CORTEX_A5x_H__
-#define __ARM_CORTEX_A5x_H__
+#ifndef ARM_CORTEX_A5X_H_
+#define ARM_CORTEX_A5X_H_
 
 //
 // Cortex A5x feature bit definitions
@@ -41,4 +41,4 @@ ArmUnsetCpuExCrBit (
   IN  UINT64Bits
   );
 
-#endif
+#endif // ARM_CORTEX_A5X_H_
diff --git a/ArmPkg/Include/Chipset/ArmV7.h b/ArmPkg/Include/Chipset/ArmV7.h
index fe91031ef33d..025f87a56d16 100644
--- a/ArmPkg/Include/Chipset/ArmV7.h
+++ b/ArmPkg/Include/Chipset/ArmV7.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-  Copyright (c) 2011-2015, ARM Ltd. All rights reserved.
+  Copyright (c) 2011-2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -70,7 +70,7 @@
 // MIDR - Main ID Register definitions
 #define ARM_CPU_TYPE_SHIFT  4
 #define ARM_CPU_TYPE_MASK   0xFFF
-#define ARM_CPU_TYPE_AEMv8  0xD0F
+#define ARM_CPU_TYPE_AEMV8  0xD0F
 #define ARM_CPU_TYPE_A530xD03
 #define ARM_CPU_TYPE_A570xD07
 #define ARM_CPU_TYPE_A150xC0F
diff --git a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S 
b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
index 5b10a1

[edk2-devel] [PATCH v3 03/26] ArmPkg: Fix Ecc error 8001 in ArmArchTimerLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Only capital letters are allowed to be used for #define
declarations

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c 
b/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c
index 24d9dae4e660..875c835706d6 100644
--- a/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c
+++ b/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c
@@ -1,7 +1,7 @@
 /** @file
   Generic ARM implementation of TimerLib.h
 
-  Copyright (c) 2011-2016, ARM Limited. All rights reserved.
+  Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -20,9 +20,9 @@
 
 // Select appropriate multiply function for platform architecture.
 #ifdef MDE_CPU_ARM
-#define MultU64xN MultU64x32
+#define MULT_U64_X_N MultU64x32
 #else
-#define MultU64xN MultU64x64
+#define MULT_U64_X_N MultU64x64
 #endif
 
 
@@ -121,7 +121,7 @@ MicroSecondDelay (
   //  = MicroSeconds x TICKS_PER_MICRO_SEC
   //  = MicroSeconds x Frequency.10^-6
   TimerTicks64 = DivU64x32 (
-   MultU64xN (
+   MULT_U64_X_N (
  MicroSeconds,
  GetPlatformTimerFreq ()
  ),
@@ -263,7 +263,7 @@ GetTimeInNanoSecond (
   // Time = - x 1,000,000,000
   //Frequency
   //
-  NanoSeconds = MultU64xN (
+  NanoSeconds = MULT_U64_X_N (
   DivU64x32Remainder (
 Ticks,
 TimerFreq,
@@ -276,7 +276,7 @@ GetTimeInNanoSecond (
   // will not overflow 64-bit.
   //
   NanoSeconds += DivU64x32 (
-   MultU64xN (
+   MULT_U64_X_N (
  (UINT64) Remainder,
  10U),
TimerFreq
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72057): https://edk2.groups.io/g/devel/message/72057
Mute This Topic: https://groups.io/mt/80850069/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 00/26] Fix Ecc reported errors in ArmPkg

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

The Ecc tools available in the BaseTools package checks for
good practice coding standards. Some errors reported while
running Ecc on the ArmPkg require modifications.

The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

v2:
For ArmPkg: Fix Ecc error 8001 in Chipset
 - Only use one trailing underscore for the
   ARM_CORTEX_A5x_H__ include guard. [Sami]
 - 2 patches had the same name and fixed the same
   Ecc error in V1. They are merged in V2. [Pierre]

v3:
 - Place ScmiMessageIdBasexxx related changes that were in
   'ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_CLOCK' in
   'ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_BASE'. [Sami]

Pierre Gondois (26):
  ArmPkg: Fix Ecc error 8001 in Chipset
  ArmPkg: Fix Ecc error 8001 in SemihostLib
  ArmPkg: Fix Ecc error 8001 in ArmArchTimerLib
  ArmPkg: Fix Ecc error 9005 in CpuDxe
  ArmPkg: Fix Ecc error 10006 in ArmPkg.dsc
  ArmPkg: Fix Ecc error 10016 in StandaloneMmMmuLib
  ArmPkg: Fix Ecc error 10014 in ArmScmiDxe
  ArmPkg: Fix Ecc error 10014 in GenericWatchdogDxe
  ArmPkg: Fix Ecc error 10014 in MmCommunicationDxe
  ArmPkg: Fix Ecc error 10014 in SemihostLib
  ArmPkg: Remove ArmGic/ArmGicSecLib.c
  ArmPkg: Fix Ecc error 5003 in ArmExceptionLib
  ArmPkg: Fix Ecc error 6001 in MmCommunicationDxe
  ArmPkg: Fix Ecc error 6001 in ArmSoftFloatLib
  ArmPkg: Rename include guard in ArmGicLib.h
  ArmPkg: Fix Ecc error 7008 for SCMI_CLOCK_RATE
  ArmPkg: Fix Ecc error 7008 for OPTEE_MESSAGE_PARAM
  ArmPkg: Fix Ecc error 8005/8007 in ArmDisassemblerLib
  ArmPkg: Fix Ecc error 8005 for SCMI_PROTOCOL_ID
  ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_TYPE
  ArmPkg: Fix Ecc error 8005 for SCMI_STATUS
  ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID
  ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_BASE
  ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_CLOCK
  ArmPkg: Fix Ecc error 8005 for SCMI_CLOCK_RATE_FORMAT
  ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_PERFORMANCE

 ArmPkg/ArmPkg.dsc |   6 +-
 ArmPkg/Drivers/ArmGic/ArmGicSecLib.c  |  58 ---
 ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf  |   9 +-
 .../ArmScmiPerformanceProtocolPrivate.h   |   4 +-
 ArmPkg/Drivers/ArmScmiDxe/Scmi.c  |  10 +-
 ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c  |  24 +--
 ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c |  44 ++---
 ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c   |  10 +-
 .../ArmScmiDxe/ScmiPerformanceProtocol.c  |  30 ++--
 ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h   |  48 +++---
 ArmPkg/Drivers/CpuDxe/CpuMpCore.c |   4 +-
 .../GenericWatchdogDxe/GenericWatchdogDxe.inf |   3 +-
 .../MmCommunicationDxe/MmCommunicate.h|   8 +-
 .../MmCommunicationDxe/MmCommunication.inf|   3 +-
 ArmPkg/Include/Chipset/AArch64.h  |  12 +-
 ArmPkg/Include/Chipset/AArch64Mmu.h   |   4 +-
 ArmPkg/Include/Chipset/ArmCortexA5x.h |   8 +-
 ArmPkg/Include/Chipset/ArmV7.h|   4 +-
 ArmPkg/Include/Library/ArmGicLib.h|   8 +-
 ArmPkg/Include/Library/OpteeLib.h |  11 +-
 ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h |  10 +-
 .../Include/Protocol/ArmScmiClock2Protocol.h  |   6 +-
 .../Include/Protocol/ArmScmiClockProtocol.h   |  32 ++--
 .../Protocol/ArmScmiPerformanceProtocol.h |  14 +-
 .../Library/ArmArchTimerLib/ArmArchTimerLib.c |  12 +-
 .../ArmDisassemblerLib/ArmDisassembler.c  | 159 +-
 .../ArmDisassemblerLib/ThumbDisassembler.c| 158 -
 .../AArch64/AArch64Exception.c|   4 +-
 .../AArch64/ExceptionSupport.S|  10 +-
 .../ArmExceptionLib/Arm/ArmException.c|   5 +-
 ArmPkg/Library/ArmSoftFloatLib/platform.h |   6 +
 ArmPkg/Library/SemihostLib/SemihostLib.c  |  26 +--
 ArmPkg/Library/SemihostLib/SemihostLib.inf|   3 +-
 ArmPkg/Library/SemihostLib/SemihostPrivate.h  |  80 -
 .../ArmMmuStandaloneMmLib.inf |   4 +-
 ArmPlatformPkg/PrePeiCore/AArch64/Exception.S |  10 +-
 36 files changed, 416 insertions(+), 431 deletions(-)
 delete mode 100644 ArmPkg/Drivers/ArmGic/ArmGicSecLib.c

--
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72054): https://edk2.groups.io/g/devel/message/72054
Mute This Topic: https://groups.io/mt/80850065/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 02/26] ArmPkg: Fix Ecc error 8001 in SemihostLib

2021-02-23 Thread PierreGondois
From: Pierre Gondois 

This patch fixes the following Ecc reported error:
Only capital letters are allowed to be used
for #define declarations

Signed-off-by: Pierre Gondois 
Reviewed-by: Sami Mujawar 
---
The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1552_Ecc_ArmPkg_BIS_v3

 ArmPkg/Library/SemihostLib/SemihostLib.c | 26 +++
 ArmPkg/Library/SemihostLib/SemihostPrivate.h | 80 ++--
 2 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/ArmPkg/Library/SemihostLib/SemihostLib.c 
b/ArmPkg/Library/SemihostLib/SemihostLib.c
index a75d45850d43..d66de71182c8 100644
--- a/ArmPkg/Library/SemihostLib/SemihostLib.c
+++ b/ArmPkg/Library/SemihostLib/SemihostLib.c
@@ -44,7 +44,7 @@ SemihostFileOpen (
   OpenBlock.Mode= Mode;
   OpenBlock.NameLength  = AsciiStrLen(FileName);
 
-  Result = Semihost_SYS_OPEN(&OpenBlock);
+  Result = SEMIHOST_SYS_OPEN (&OpenBlock);
 
   if (Result == -1) {
 return RETURN_NOT_FOUND;
@@ -66,7 +66,7 @@ SemihostFileSeek (
   SeekBlock.Handle   = FileHandle;
   SeekBlock.Location = Offset;
 
-  Result = Semihost_SYS_SEEK(&SeekBlock);
+  Result = SEMIHOST_SYS_SEEK (&SeekBlock);
 
   // Semihosting does not behave as documented. It returns the offset on
   // success.
@@ -95,7 +95,7 @@ SemihostFileRead (
   ReadBlock.Buffer = Buffer;
   ReadBlock.Length = *Length;
 
-  Result = Semihost_SYS_READ(&ReadBlock);
+  Result = SEMIHOST_SYS_READ (&ReadBlock);
 
   if ((*Length != 0) && (Result == *Length)) {
 return RETURN_ABORTED;
@@ -122,7 +122,7 @@ SemihostFileWrite (
   WriteBlock.Buffer = Buffer;
   WriteBlock.Length = *Length;
 
-  *Length = Semihost_SYS_WRITE(&WriteBlock);
+  *Length = SEMIHOST_SYS_WRITE (&WriteBlock);
 
   if (*Length != 0)
 return RETURN_ABORTED;
@@ -135,7 +135,7 @@ SemihostFileClose (
   IN UINTN  FileHandle
   )
 {
-  if (Semihost_SYS_CLOSE (&FileHandle) == -1) {
+  if (SEMIHOST_SYS_CLOSE (&FileHandle) == -1) {
 return RETURN_INVALID_PARAMETER;
   } else {
 return RETURN_SUCCESS;
@@ -154,7 +154,7 @@ SemihostFileLength (
 return RETURN_INVALID_PARAMETER;
   }
 
-  Result = Semihost_SYS_FLEN(&FileHandle);
+  Result = SEMIHOST_SYS_FLEN (&FileHandle);
 
   if (Result == -1) {
 return RETURN_ABORTED;
@@ -195,7 +195,7 @@ SemihostFileTmpName(
   TmpNameBlock.Identifier = Identifier;
   TmpNameBlock.Length = Length;
 
-  Result = Semihost_SYS_TMPNAME (&TmpNameBlock);
+  Result = SEMIHOST_SYS_TMPNAME (&TmpNameBlock);
 
   if (Result != 0) {
 return  RETURN_ABORTED;
@@ -220,7 +220,7 @@ SemihostFileRemove (
   RemoveBlock.FileName= FileName;
   RemoveBlock.NameLength  = AsciiStrLen(FileName);
 
-  Result = Semihost_SYS_REMOVE(&RemoveBlock);
+  Result = SEMIHOST_SYS_REMOVE (&RemoveBlock);
 
   if (Result == 0) {
 return RETURN_SUCCESS;
@@ -258,7 +258,7 @@ SemihostFileRename(
   RenameBlock.NewFileName   = NewFileName;
   RenameBlock.NewFileNameLength = AsciiStrLen (NewFileName);
 
-  Result = Semihost_SYS_RENAME (&RenameBlock);
+  Result = SEMIHOST_SYS_RENAME (&RenameBlock);
 
   if (Result != 0) {
 return  RETURN_ABORTED;
@@ -272,7 +272,7 @@ SemihostReadCharacter (
   VOID
   )
 {
-  return Semihost_SYS_READC();
+  return SEMIHOST_SYS_READC ();
 }
 
 VOID
@@ -280,7 +280,7 @@ SemihostWriteCharacter (
   IN CHAR8 Character
   )
 {
-  Semihost_SYS_WRITEC(&Character);
+  SEMIHOST_SYS_WRITEC (&Character);
 }
 
 VOID
@@ -288,7 +288,7 @@ SemihostWriteString (
   IN CHAR8 *String
   )
 {
-  Semihost_SYS_WRITE0(String);
+  SEMIHOST_SYS_WRITE0 (String);
 }
 
 UINT32
@@ -301,5 +301,5 @@ SemihostSystem (
   SystemBlock.CommandLine   = CommandLine;
   SystemBlock.CommandLength = AsciiStrLen(CommandLine);
 
-  return Semihost_SYS_SYSTEM(&SystemBlock);
+  return SEMIHOST_SYS_SYSTEM (&SystemBlock);
 }
diff --git a/ArmPkg/Library/SemihostLib/SemihostPrivate.h 
b/ArmPkg/Library/SemihostLib/SemihostPrivate.h
index 8d1fc6d6eb5a..30103b04b53f 100644
--- a/ArmPkg/Library/SemihostLib/SemihostPrivate.h
+++ b/ArmPkg/Library/SemihostLib/SemihostPrivate.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-  Copyright (c) 2013 - 2014, ARM Ltd. All rights reserved.
+  Copyright (c) 2013 - 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -151,19 +151,19 @@ _Semihost_SYS_SYSTEM(
   IN SEMIHOST_SYSTEM_BLOCK *SystemBlock
   );
 
-#define Semihost_SYS_OPEN(OpenBlock)_Semihost_SYS_OPEN(0x01, OpenBlock)
-#define Semihost_SYS_CLOSE(Handle)  _Semihost_SYS_CLOSE(0x02, Handle)
-#define Semihost_SYS_WRITE0(String) _Semihost_SYS_WRITE0(0x04, String)
-#define Semihost_SYS_WRITEC(Character)  _Semihost_SYS_WRITEC(0x03, 
Character)
-#define Semihost_SYS_WRITE(WriteBlock)  _Semihost_SYS_WRITE(0x05, 
WriteBlock)
-#define Semihost_SYS_READ(ReadBlock)_Semihost_SYS_READ(0x06, ReadBlock)
-#define Semihost_SYS_READC()_Semihost_SYS_READC(0x07, 0)
-#define Semihost_SYS_SEEK(SeekBlock) 

Re: [edk2-devel] [PATCH edk2 v2 1/1] ArmPkg/ArmGic: Fix GICR_IPRIORITYR address wrong issue

2021-02-23 Thread Leif Lindholm
On Tue, Feb 23, 2021 at 20:58:14 +0800, Heyi Guo wrote:
> 
> On 2021/2/23 下午7:06, Ming Huang wrote:
> > The register address of GICR_IPRIORITYR is in SGI_base frame. Add
> > IPRIORITY_ADDRESS macro for getting GICR_IPRIORITYR address. Otherwise
> > GIC RAS error(Uncorrected software error) may report in ArmGicDxe.
> > ---
> >   ArmPkg/Drivers/ArmGic/ArmGicLib.c | 5 -
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
> > b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > index 8ef32b33a1..b4d3965acb 100644
> > --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > @@ -30,6 +30,9 @@
> >   #define ICENABLER_ADDRESS(base,offset) ((base) + \
> > ARM_GICR_CTLR_FRAME_SIZE +  ARM_GICR_ICENABLER + (4 * offset))
> > +#define IPRIORITY_ADDRESS(base,offset) ((base) + \
> > +  ARM_GICR_CTLR_FRAME_SIZE +  ARM_GIC_ICDIPR + (4 * offset))
> 
> For macro parameter, I think we need to put "offset" in parentheses, and it
> is not necessary to put 4 * offset inside parentheses.

You are correct.

> How about adding one more patch to fix the existing macros ICENABLER_ADDRESS
> and ISENABLER_ADDRESS first and then this patch?

If Ming could spin that at the same time as adding Signed-off-by, that
would be ideal.

Thanks!

/
Leif

> Thanks,
> 
> Heyi
> 
> 
> > +
> >   /**
> >*
> >* Return whether the Source interrupt index refers to a shared interrupt 
> > (SPI)
> > @@ -236,7 +239,7 @@ ArmGicSetInterruptPriority (
> >   }
> >   MmioAndThenOr32 (
> > -  GicCpuRedistributorBase + ARM_GIC_ICDIPR + (4 * RegOffset),
> > +  IPRIORITY_ADDRESS (GicCpuRedistributorBase, RegOffset),
> > ~(0xff << RegShift),
> > Priority << RegShift
> > );
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72053): https://edk2.groups.io/g/devel/message/72053
Mute This Topic: https://groups.io/mt/80848339/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2 v2 1/1] ArmPkg/ArmGic: Fix GICR_IPRIORITYR address wrong issue

2021-02-23 Thread Heyi Guo



On 2021/2/23 下午7:06, Ming Huang wrote:

The register address of GICR_IPRIORITYR is in SGI_base frame. Add
IPRIORITY_ADDRESS macro for getting GICR_IPRIORITYR address. Otherwise
GIC RAS error(Uncorrected software error) may report in ArmGicDxe.
---
  ArmPkg/Drivers/ArmGic/ArmGicLib.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
index 8ef32b33a1..b4d3965acb 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
@@ -30,6 +30,9 @@
  #define ICENABLER_ADDRESS(base,offset) ((base) + \
ARM_GICR_CTLR_FRAME_SIZE +  ARM_GICR_ICENABLER + (4 * offset))
  
+#define IPRIORITY_ADDRESS(base,offset) ((base) + \

+  ARM_GICR_CTLR_FRAME_SIZE +  ARM_GIC_ICDIPR + (4 * offset))


For macro parameter, I think we need to put "offset" in parentheses, and 
it is not necessary to put 4 * offset inside parentheses.


How about adding one more patch to fix the existing macros 
ICENABLER_ADDRESS and ISENABLER_ADDRESS first and then this patch?


Thanks,

Heyi



+
  /**
   *
   * Return whether the Source interrupt index refers to a shared interrupt 
(SPI)
@@ -236,7 +239,7 @@ ArmGicSetInterruptPriority (
  }
  
  MmioAndThenOr32 (

-  GicCpuRedistributorBase + ARM_GIC_ICDIPR + (4 * RegOffset),
+  IPRIORITY_ADDRESS (GicCpuRedistributorBase, RegOffset),
~(0xff << RegShift),
Priority << RegShift
);



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72052): https://edk2.groups.io/g/devel/message/72052
Mute This Topic: https://groups.io/mt/80848339/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2 v2 1/1] ArmPkg/ArmGic: Fix GICR_IPRIORITYR address wrong issue

2021-02-23 Thread Leif Lindholm
On Tue, Feb 23, 2021 at 13:42:49 +0100, Ard Biesheuvel wrote:
> On Tue, 23 Feb 2021 at 12:07, Ming Huang  wrote:
> >
> > The register address of GICR_IPRIORITYR is in SGI_base frame. Add
> > IPRIORITY_ADDRESS macro for getting GICR_IPRIORITYR address. Otherwise
> > GIC RAS error(Uncorrected software error) may report in ArmGicDxe.
> 
> NOTE: missing sign-off
> 
> Patch seems fine to me
> 
> Tested-by: Ard Biesheuvel  # QEMU/kvm guest on ThunderX2

Also looks good in QEMU.
Reviewed-by: Leif Lindholm 

Ming, can you confirm that the contribution conforms to the developer
certificate of origin by replyint with your Signed-off-by: ?

> 
> 
> 
> > ---
> >  ArmPkg/Drivers/ArmGic/ArmGicLib.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
> > b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > index 8ef32b33a1..b4d3965acb 100644
> > --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > @@ -30,6 +30,9 @@
> >  #define ICENABLER_ADDRESS(base,offset) ((base) + \
> >ARM_GICR_CTLR_FRAME_SIZE +  ARM_GICR_ICENABLER + (4 * offset))
> >
> > +#define IPRIORITY_ADDRESS(base,offset) ((base) + \
> > +  ARM_GICR_CTLR_FRAME_SIZE +  ARM_GIC_ICDIPR + (4 * offset))
> > +
> >  /**
> >   *
> >   * Return whether the Source interrupt index refers to a shared interrupt 
> > (SPI)
> > @@ -236,7 +239,7 @@ ArmGicSetInterruptPriority (
> >  }
> >
> >  MmioAndThenOr32 (
> > -  GicCpuRedistributorBase + ARM_GIC_ICDIPR + (4 * RegOffset),
> > +  IPRIORITY_ADDRESS (GicCpuRedistributorBase, RegOffset),
> >~(0xff << RegShift),
> >Priority << RegShift
> >);
> > --
> > 2.17.1
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72051): https://edk2.groups.io/g/devel/message/72051
Mute This Topic: https://groups.io/mt/80848339/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2 v2 1/1] ArmPkg/ArmGic: Fix GICR_IPRIORITYR address wrong issue

2021-02-23 Thread Ard Biesheuvel
On Tue, 23 Feb 2021 at 12:07, Ming Huang  wrote:
>
> The register address of GICR_IPRIORITYR is in SGI_base frame. Add
> IPRIORITY_ADDRESS macro for getting GICR_IPRIORITYR address. Otherwise
> GIC RAS error(Uncorrected software error) may report in ArmGicDxe.

NOTE: missing sign-off

Patch seems fine to me

Tested-by: Ard Biesheuvel  # QEMU/kvm guest on ThunderX2



> ---
>  ArmPkg/Drivers/ArmGic/ArmGicLib.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
> b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> index 8ef32b33a1..b4d3965acb 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> @@ -30,6 +30,9 @@
>  #define ICENABLER_ADDRESS(base,offset) ((base) + \
>ARM_GICR_CTLR_FRAME_SIZE +  ARM_GICR_ICENABLER + (4 * offset))
>
> +#define IPRIORITY_ADDRESS(base,offset) ((base) + \
> +  ARM_GICR_CTLR_FRAME_SIZE +  ARM_GIC_ICDIPR + (4 * offset))
> +
>  /**
>   *
>   * Return whether the Source interrupt index refers to a shared interrupt 
> (SPI)
> @@ -236,7 +239,7 @@ ArmGicSetInterruptPriority (
>  }
>
>  MmioAndThenOr32 (
> -  GicCpuRedistributorBase + ARM_GIC_ICDIPR + (4 * RegOffset),
> +  IPRIORITY_ADDRESS (GicCpuRedistributorBase, RegOffset),
>~(0xff << RegShift),
>Priority << RegShift
>);
> --
> 2.17.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72050): https://edk2.groups.io/g/devel/message/72050
Mute This Topic: https://groups.io/mt/80848339/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v3 0/3] ArmPkg: Fix several issues in OemMiscLib

2021-02-23 Thread Leif Lindholm
On Mon, Feb 22, 2021 at 21:53:50 -0700, Rebecca Cran wrote:
> Update OemMiscLib with the following changes:
> 
> o Fixed ordering of return type and EFIAPI specifier.
> o Renamed 'mHiiHandle' parameter in OemUpdateSmbiosInfo to 'HiiHandle'.
> o Renamed 'Offset' parameter in OemUpdateSmbiosInfo to 'Field'.
> o Renamed OemGetProcessorMaxSockets to OemGetMaxProcessors.
> o Renamed OemIsSocketPresent to OemIsProcessorPresent.
> o Updated OemGetChassisType to return MISC_CHASSIS_TYPE instead of
>   EFI_STATUS, which matches other OemMiscLib functions.
> 
> Github pull request (personal build): 
> https://github.com/tianocore/edk2/pull/1435
> 
> Changes between v2 and v3:
> 
> Moved the OemGetChassisType changes from 2/3 to 3/3.
> Renamed the 'mHiiHandle' parameter in OemUpdateSmbiosInfo to 'HiiHandle'.

For the series:
Reviewed-by: Leif Lindholm 
Pushed as 078400ee15e7..a2b5ea38a6fb.

Thanks!

> 
> Rebecca Cran (3):
>   ArmPkg: Fix ordering of return type and EFIAPI specifier in OemMiscLib
>   ArmPkg: Rename some functions and parameters in OemMiscLib
>   ArmPkg: Update OemGetChassisType function to return MISC_CHASSIS_TYPE
> 
>  ArmPkg/Include/Library/OemMiscLib.h  
>   | 34 -
>  ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c  
>   | 40 +---
>  ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c 
>   | 40 ++--
>  
> ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type03/MiscChassisManufacturerFunction.c
>  | 28 +-
>  4 files changed, 55 insertions(+), 87 deletions(-)
> 
> -- 
> 2.26.2
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72049): https://edk2.groups.io/g/devel/message/72049
Mute This Topic: https://groups.io/mt/80844865/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2] RedfishPkg/RedfishCrtLib: Add more CRT functions

2021-02-23 Thread Leif Lindholm
On Thu, Feb 18, 2021 at 03:13:38 +, Chang, Abner (HPS SW/FW Technologist) 
wrote:
> Hi Leif,
> Have time to review the v2 which was revised according to your comments on v1.

Whoops, sorry.

I am a bit unsure how to treat reviews of RedfishPkg, which I'm not a
reviewer/maintainer for. If I just point out a few minor fixups (like
here), you don't really need to wait for my confirmation.
I had sort of moved on and considered this set done from my point of
view, lazily ignoring the thread.

But if you want it:
Acked-by: Leif Lindholm 


> Thanks
> Abner
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Abner Chang
> > Sent: Thursday, January 28, 2021 10:58 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Nickle (HPS SW) ; Leif Lindholm
> > ; Michael D Kinney 
> > Subject: [edk2-devel] [PATCH v2] RedfishPkg/RedfishCrtLib: Add more CRT
> > functions
> > 
> > Add more functions which were missed in the first time commit, that causes
> > the build error with EDK2 Redfish feature driver.
> > 
> > strerror - We don't support this on edk2 environment.
> > strpbrk  - Cloned this function from edk2-LibC File operation functions - 
> > Not
> > supported on edk2 environment.
> > 
> > Signed-off-by: Abner Chang 
> > 
> > Cc: Nickle Wang 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > ---
> >  .../RedfishCrtLib/RedfishCrtLib.c | 122 +-
> >  1 file changed, 121 insertions(+), 1 deletion(-)
> > 
> > diff --git a/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c
> > b/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c
> > index 0696341bc0..58ef4f8fdb 100644
> > --- a/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c
> > +++ b/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c
> > @@ -15,6 +15,10 @@
> >  #include 
> > 
> >  int  errno = 0;
> > +char errnum_message [] = "We don't support to map errnum to the error
> > +message on edk2 Redfish\n";
> > +
> > +// This is required to keep VC++ happy if you use floating-point int
> > +_fltused  = 1;
> > 
> >  /**
> >Determine if a particular character is an alphanumeric character @@ 
> > -465,6
> > +469,77 @@ strtod (const char * __restrict nptr, char ** __restrict endptr) 
> > {
> >  return (double)0;
> >  }
> > 
> > +static UINT8  BitMask[] = {
> > +  0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
> > +  };
> > +
> > +#define WHICH8(c) ((unsigned char)(c) >> 3)
> > +#define WHICH_BIT(c)  (BitMask[((c) & 0x7)])
> > +#define BITMAP64  ((UINT64 *)bitmap)
> > +
> > +static
> > +void
> > +BuildBitmap(unsigned char * bitmap, const char *s2, int n) {
> > +  unsigned char bit;
> > +  int   index;
> > +
> > +  // Initialize bitmap.  Bit 0 is always 1 which corresponds to '\0'
> > +  for (BITMAP64[0] = index = 1; index < n; index++) {
> > +BITMAP64[index] = 0;
> > +  }
> > +
> > +  // Set bits in bitmap corresponding to the characters in s2
> > +  for (; *s2 != '\0'; s2++) {
> > +index = WHICH8(*s2);
> > +bit = WHICH_BIT(*s2);
> > +bitmap[index] = bitmap[index] | bit;
> > +  }
> > +}
> > +
> > +/** The strpbrk function locates the first occurrence in the string 
> > pointed to
> > +by s1 of any character from the string pointed to by s2.
> > +
> > +@return   The strpbrk function returns a pointer to the character, or a
> > +  null pointer if no character from s2 occurs in s1.
> > +**/
> > +char *
> > +strpbrk(const char *s1, const char *s2) {
> > +  UINT8 bitmap[ (((UCHAR_MAX + 1) / CHAR_BIT) + (CHAR_BIT - 1)) & ~7U];
> > +  UINT8 bit;
> > +  int index;
> > +
> > +  BuildBitmap( bitmap, s2, sizeof(bitmap) / sizeof(UINT64));
> > +
> > +  for( ; *s1 != '\0'; ++s1) {
> > +index = WHICH8(*s1);
> > +bit = WHICH_BIT(*s1);
> > +if( (bitmap[index] & bit) != 0) {
> > +  return (char *)s1;
> > +}
> > +  }
> > +  return NULL;
> > +}
> > +
> > +/** The strerror function maps the number in errnum to a message string.
> > +Typically, the values for errnum come from errno, but strerror shall 
> > map
> > +any value of type int to a message.
> > +
> > +The implementation shall behave as if no library function calls the
> > +strerror function.
> > +
> > +@return   The strerror function returns a pointer to the string, the
> > +  contents of which are locale specific.  The array pointed to
> > +  shall not be modified by the program, but may be overwritten 
> > by
> > +  a subsequent call to the strerror function.
> > +**/
> > +char *
> > +strerror(int errnum)
> > +{
> > +  return errnum_message;
> > +}
> > +
> >  /**
> >Allocate and zero-initialize array.
> >  **/
> > @@ -592,7 +667,52 @@ void qsort (void *base, size_t num, size_t width, int
> > (*compare)(const void *, c
> > 
> >  **/
> >  int fgetc(FILE * _File){
> > -   return 0;
> > +   return EOF;
> > +}
> > +/**
> > +  Open stream file, we don't support file operastion on edk2 JSON library.
> > +

Re: [edk2-devel] [PATCH edk2-platforms v1 1/1] Platform/Arm: Fix Ecc error 7008 for SCMI_CLOCK_RATE

2021-02-23 Thread Sami Mujawar
Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72047): https://edk2.groups.io/g/devel/message/72047
Mute This Topic: https://groups.io/mt/80563972/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




  1   2   >