Re: [edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Sunny Wang]

Thanks for the review, Pete. I just sent v2 for addressing all your comments 
except the one below.

> -#define BOOT_PROMPT L"ESC (setup), F1 (shell), ENTER (boot)"
>
> +#define BOOT_PROMPT L"ESC (setup), F1 (shell), ENTER (boot)\n"

Why are you adding the carriage return? Was there an issue with the display of 
this prompt?

[Sunny] Yeah, I saw a display issue in the serial log. This message would be 
stuck to the next message (either screen or serial message) like the following:
 - ESC (setup), F1 (shell), ENTER (boot)UsbBusRecursivelyConnectWantedUsbIo: 
TPL before connect is 4
 - ESC (setup), F1 (shell), ENTER (boot)Boot Policy is Full Discovery. Connect 
all devices

Best Regards,
Sunny Wang

-Original Message-
From: Pete Batard 
Sent: Monday, April 12, 2021 9:04 PM
To: Sunny Wang ; devel@edk2.groups.io
Cc: Samer El-Haj-Mahmoud ; Jeremy Linton 
; Ard Biesheuvel 
Subject: Re: [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast 
Boot

Hi Sunny,

Functionaly, I see no issues with this patch, and it's indeed a good solution 
to the problem of trying to satisfy everyone while fixing the issues we are 
seeing.

There are however a few minor typos and whitespace issues, that I'm detailing 
below. So could you please send a v2 to address these?

On 2021.04.12 10:05, Sunny Wang wrote:
> This is a fix for https://github.com/pftf/RPi4/issues/114.
>
> Changes:
>1. Add a setup option called Boot Policy and consume the setting
>   during boot to whether perform or skip ConnectAll.
>2. The Default setting is set to Full discovery because it is not
>   worth enabling Fast boot by default on RaspberryPi systems.
>   Enabling it just saves boot time about 1 second, but caused a
>   lot of issues.
>
> Testing Done:
>- Booted to Standalone UEFI shell on SD card and use drivers
>  command to check the result with Fast Boot and Full discovery
>  settings. Then, child/device handles are created as expected.
>
> Note and to-do items:
>- The root cause looks like that boot loaders and some tools like
>  grub and iPXE haven't supported selective connect/Fast boot.
>  However, system firmware should still provide a setup option for
>  user to enable Fast boot with old version boot loaders and tools
>  , which is why we proposed this change. We will also report this
>  issue to boot loader and tool vendors/open source GitHubs.
>- We Will add more options for connecting specific type devices so
>  that we can still have the shortest boot time for all use cases.
>
> Cc: Samer El-Haj-Mahmoud 
> Cc: Jeremy Linton 
> Cc: Pete Batard 
> Cc: Ard Biesheuvel 
> Signed-off-by: Sunny Wang 
> ---
>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
>   .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
>   .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
>   Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
>   .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
>   .../PlatformBootManagerLib.inf   |  1 +
>   Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
>   Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
>   Platform/RaspberryPi/RaspberryPi.dec |  2 ++
>   10 files changed, 80 insertions(+), 9 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> index 22f86d4d44..d3c5869949 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> @@ -1,6 +1,6 @@
>   /** @file
>
>*
>
> - *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
>
> + *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
>
>*  Copyright (c) 2018 - 2020, Andrei Warkentin
> 
>
>*
>
>*  SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -281,6 +281,15 @@ SetupVariables (
>   );
>
> }
>
>
>
> +  Size = sizeof (UINT32);
>
> +  Status = gRT->GetVariable (L"BootPolicy",
>
> +  ,
>
> +  NULL, , );
>
> +  if (EFI_ERROR (Status)) {
>
> +Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));
>
> +ASSERT_EFI_ERROR (Status);
>
> +  }
>
> +
>
> Size = sizeof (UINT32);
>
> Status = gRT->GetVariable (L"SdIsArasan",
>
> ,
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> index d51e54e010..032e40b0c3 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> @@ -2,7 +2,7 @@
>   #
>
>   #  Component description file for the RasbperryPi DXE platform config 
> driver.
>
>   #
>
> -#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
>
> +#  Copyright (c) 

[edk2-devel] [PATCH v2 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Sunny Wang]

This is a fix for https://github.com/pftf/RPi4/issues/114.

Changes:
  1. Add a setup option called Boot Policy and consume the setting
 during boot to whether perform or skip ConnectAll.
  2. The Default setting is set to Full discovery because it is not
 worth enabling Fast boot by default on RaspberryPi systems.
 Enabling it just saves boot time about 1 second, but caused a
 lot of issues.

Testing Done:
  - Booted to Standalone UEFI shell on SD card and use drivers
command to check the result with Fast Boot and Full discovery
settings. Then, child/device handles are created as expected.

Note and to-do items:
  - The root cause looks like that boot loaders and some tools like
grub and iPXE haven't supported selective connect/Fast boot.
However, system firmware should still provide a setup option for
user to enable Fast boot with old version boot loaders and tools
, which is why we proposed this change. We will also report this
issue to boot loader and tool vendors/open source GitHubs.
  - We Will add more options for connecting specific type devices so
that we can still have the shortest boot time for all use cases.

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Sami Mujawar 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
 .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 16 +++-
 Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
 .../Library/PlatformBootManagerLib/PlatformBm.c  | 15 +--
 .../PlatformBootManagerLib.inf   |  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc   |  9 -
 Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
 Platform/RaspberryPi/RaspberryPi.dec |  2 ++
 10 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 22f86d4d44..d3c5869949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -1,6 +1,6 @@
 /** @file
  *
- *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
  *  Copyright (c) 2018 - 2020, Andrei Warkentin 
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -281,6 +281,15 @@ SetupVariables (
 );
   }
 
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"BootPolicy",
+  ,
+  NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));
+ASSERT_EFI_ERROR (Status);
+  }
+
   Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"SdIsArasan",
   ,
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index d51e54e010..032e40b0c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
 #
 #  Component description file for the RasbperryPi DXE platform config driver.
 #
-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
 #  Copyright (c) 2018 - 2020, Andrei Warkentin 
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -93,6 +93,7 @@
   gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
   gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
+  gRaspberryPiTokenSpaceGuid.PcdBootPolicy
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..81761d64bb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -1,7 +1,7 @@
 /** @file
  *
  *  Copyright (c) 2018, Andrei Warkentin 
- *  Copyright (c) 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
  *
@@ -60,6 +60,14 @@
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
+#string STR_BOOT_POLICY_PROMPT#language en-US "Boot Policy"
+#string STR_BOOT_POLICY_HELP  #language en-US "When Fast Boot is 
selected, only required devices will be discovered for reducing "
+  "the boot time. "
+  "When Full Discovery is 
selected, all the devices will be discovered for some "
+

Re: [edk2-devel] [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be predefined

[Abner Chang]

> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Tuesday, April 13, 2021 10:38 AM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> devel@edk2.groups.io; Kinney, Michael D 
> Cc: Liming Gao ; Liu, Zhiguang
> ; Andrew Fish 
> Subject: RE: [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be
> predefined
> 
> 
> 
> > -Original Message-
> > From: Chang, Abner (HPS SW/FW Technologist) 
> > Sent: Monday, April 12, 2021 6:57 PM
> > To: Kinney, Michael D ;
> devel@edk2.groups.io
> > Cc: Liming Gao ; Liu, Zhiguang
> ; Andrew Fish 
> > Subject: RE: [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be
> predefined
> >
> >
> >
> > > -Original Message-
> > > From: Michael D Kinney [mailto:michael.d.kin...@intel.com]
> > > Sent: Thursday, April 8, 2021 2:33 PM
> > > To: devel@edk2.groups.io
> > > Cc: Liming Gao ; Zhiguang Liu
> > > ; Andrew Fish ; Chang,
> Abner
> > > (HPS SW/FW Technologist) 
> > > Subject: [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be
> > > predefined
> > >
> > > REF:
> > >
> INVALID URI REMOVED
> > >
> d=3308__;!!NpxR!2tD2XaYHZQmaFB9Nkxl0iin7W5JxSmdDV0VxeaVsY76lOFR
> > > nfql_W6kvYXu66fA$
> > >
> > > The EDK II Build Specifications do not restrict the set of
> > > CPU architectures that can be supported.  Remove places in
> > > the EDK II that assume a fixed set of CPU architectures.
> > >
> > > Update the following 3 DEFINES to allow them to be predefined
> > > on the EDK II build command line using /D flags or in DSC file
> > > [BuildOptions] sections.
> > >
> > > * EFI_IMAGE_MACHINE_TYPE_SUPPORTED
> > > * EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED
> > > * EFI_REMOVABLE_MEDIA_FILE_NAME
> > >
> > > Cc: Liming Gao 
> > > Cc: Zhiguang Liu 
> > > Cc: Andrew Fish 
> > > Cc: Abner Chang 
> > > Signed-off-by: Michael D Kinney 
> > > ---
> > >  MdePkg/Include/Uefi/UefiBaseType.h | 4 +++-
> > >  MdePkg/Include/Uefi/UefiSpec.h | 4 +++-
> > >  2 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> > > b/MdePkg/Include/Uefi/UefiBaseType.h
> > > index 934fc07285d9..92ffeb4c63d5 100644
> > > --- a/MdePkg/Include/Uefi/UefiBaseType.h
> > > +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> > > @@ -1,7 +1,7 @@
> > >  /** @file
> > >Defines data types and constants introduced in UEFI.
> > >
> > > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > > +Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
> > >  Portions copyright (c) 2011 - 2016, ARM Ltd. All rights reserved.
> > >  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> > > reserved.
> > >
> > > @@ -248,6 +248,7 @@ typedef union {
> > >  #define EFI_IMAGE_MACHINE_RISCV64   0x5064
> > >  #define EFI_IMAGE_MACHINE_RISCV128  0x5128
> > >
> > > +#if !defined(EFI_IMAGE_MACHINE_TYPE_SUPPORTED)
> > What if EFI_IMAGE_MACHINE_TYPE_SUPPORTED is predefined in /D but
> EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED is not?
> > Throw a warning message or just fix it when build error happens?
> >
> > Abner
> >
> 
> I was thinking a build error when it is referenced would be sufficient.
> 
> The other option is to generate an immediate #error if only one of the two
> are predefined.
Yes, this one is better.
Abner
> 
> > >  #if   defined (MDE_CPU_IA32)
> > >
> > >  #define EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) \
> > > @@ -294,5 +295,6 @@ typedef union {
> > >  #else
> > >  #error Unknown Processor Type
> > >  #endif
> > > +#endif
> > >
> > >  #endif
> > > diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> > > b/MdePkg/Include/Uefi/UefiSpec.h
> > > index 2b1b72d86286..8aeaebc44fd8 100644
> > > --- a/MdePkg/Include/Uefi/UefiSpec.h
> > > +++ b/MdePkg/Include/Uefi/UefiSpec.h
> > > @@ -5,7 +5,7 @@
> > >If a code construct is defined in the UEFI 2.7 specification it must be
> > > included
> > >by this include file.
> > >
> > > -Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > > +Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
> > >  Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP.
> All
> > > rights reserved.
> > >
> > >  SPDX-License-Identifier: BSD-2-Clause-Patent
> > > @@ -2211,6 +2211,7 @@ typedef struct {
> > >  #define EFI_REMOVABLE_MEDIA_FILE_NAME_AARCH64
> > > L"\\EFI\\BOOT\\BOOTAA64.EFI"
> > >  #define EFI_REMOVABLE_MEDIA_FILE_NAME_RISCV64
> > > L"\\EFI\\BOOT\\BOOTRISCV64.EFI"
> > >
> > > +#if !defined(EFI_REMOVABLE_MEDIA_FILE_NAME)
> > >  #if   defined (MDE_CPU_IA32)
> > >#define EFI_REMOVABLE_MEDIA_FILE_NAME
> > > EFI_REMOVABLE_MEDIA_FILE_NAME_IA32
> > >  #elif defined (MDE_CPU_X64)
> > > @@ -2225,6 +2226,7 @@ typedef struct {
> > >  #else
> > >#error Unknown Processor Type
> > >  #endif
> > > +#endif
> > >
> > >  //
> > >  // The directory within the active EFI System Partition defined for
> delivery of
> > > capsule to firmware
> > > --
> > > 2.31.1.windows.1
> >

Re: [edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS and MAKE_PATH fixes

[Michael D Kinney]

Liming,

The BZ contains an example of MAKE_FLAGS in DSC that breaks the build.  With 
this change,
that example passes and shows the additional make tool output.

Mike

> -Original Message-
> From: gaoliming 
> Sent: Monday, April 12, 2021 6:31 PM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Feng, Bob C ; Chen, Christine 
> Subject: 回复: [edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS 
> and MAKE_PATH fixes
> 
> Mike:
>   I don't see the issue in the code change. I want to know what unit test
> has been done for this change.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Michael D
> > Kinney
> > 发送时间: 2021年4月10日 5:49
> > 收件人: devel@edk2.groups.io
> > 抄送: Bob Feng ; Liming Gao
> > ; Yuwei Chen 
> > 主题: [edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS
> > and MAKE_PATH fixes
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3312
> >
> > Update parsing of MAKE_FLAGS in DSC [BuildOptions] sections
> > to split the flags into a list to be compatible with
> > running the make command using Popen().  Parsing MAKE_FLAGS
> > from tools_def.txt already uses _SplitOption().  This change
> > uses the same _SplitOption() method for MAKE_FLAGS from a
> > DSC [BuildOptions] section.
> >
> > Also update the parsing of MAKE_PATH to support MAKE_PATH
> > from tools_def.txt or the DSC [BuildOptions] section.  MAKE_PATH
> > in DSC [BuildOptions] section is higher priority than MAKE_PATH
> > in tools_def.txt.
> >
> > Cc: Bob Feng 
> > Cc: Liming Gao 
> > Cc: Yuwei Chen 
> > Signed-off-by: Michael D Kinney 
> > ---
> >  .../Source/Python/AutoGen/PlatformAutoGen.py  | 36 +++
> >  1 file changed, 21 insertions(+), 15 deletions(-)
> >
> > diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > index 7d8e7b3c7cc1..c16f2e4cd8b7 100644
> > --- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > +++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > @@ -1,7 +1,7 @@
> >  ## @file
> >  # Create makefile for MS nmake and GNU make
> >  #
> > -# Copyright (c) 2019, Intel Corporation. All rights reserved.
> > +# Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
> >  #  Copyright (c) 2020, ARM Limited. All rights reserved.
> >  # SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #
> > @@ -805,20 +805,26 @@ class PlatformAutoGen(AutoGen):
> >  #
> >  @cached_property
> >  def BuildCommand(self):
> > -RetVal = []
> > -if "MAKE" in self.ToolDefinition and "PATH" in
> > self.ToolDefinition["MAKE"]:
> > -RetVal += _SplitOption(self.ToolDefinition["MAKE"]["PATH"])
> > -if "FLAGS" in self.ToolDefinition["MAKE"]:
> > -NewOption =
> > self.ToolDefinition["MAKE"]["FLAGS"].strip()
> > -if NewOption != '':
> > -RetVal += _SplitOption(NewOption)
> > -if "MAKE" in self.EdkIIBuildOption:
> > -if "FLAGS" in self.EdkIIBuildOption["MAKE"]:
> > -Flags = self.EdkIIBuildOption["MAKE"]["FLAGS"]
> > -if Flags.startswith('='):
> > -RetVal = [RetVal[0]] + [Flags[1:]]
> > -else:
> > -RetVal.append(Flags)
> > +if "MAKE" in self.EdkIIBuildOption and "PATH" in
> > self.EdkIIBuildOption["MAKE"]:
> > +# MAKE_PATH in DSC [BuildOptions] section is higher priority
> > +Path = self.EdkIIBuildOption["MAKE"]["PATH"]
> > +if Path.startswith('='):
> > +Path = Path[1:].strip()
> > +RetVal = _SplitOption(Path)
> > +elif "MAKE" in self.ToolDefinition and "PATH" in
> > self.ToolDefinition["MAKE"]:
> > +RetVal = _SplitOption(self.ToolDefinition["MAKE"]["PATH"])
> > +else:
> > +return []
> > +if "MAKE" in self.ToolDefinition and "FLAGS" in
> > self.ToolDefinition["MAKE"]:
> > +NewOption = self.ToolDefinition["MAKE"]["FLAGS"].strip()
> > +if NewOption != '':
> > +RetVal += _SplitOption(NewOption)
> > +if "MAKE" in self.EdkIIBuildOption and "FLAGS" in
> > self.EdkIIBuildOption["MAKE"]:
> > +Flags = self.EdkIIBuildOption["MAKE"]["FLAGS"]
> > +if Flags.startswith('='):
> > +RetVal = [RetVal[0]] + _SplitOption(Flags[1:].strip())
> > +else:
> > +RetVal = RetVal + _SplitOption(Flags.strip())
> >  return RetVal
> >
> >  ## Get tool chain definition
> > --
> > 2.31.1.windows.1
> >
> >
> >
> > 
> >
> 
> 



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

Re: [edk2-devel] [Patch 0/3] Remove fixed CPU architecture list assumptions

[Michael D Kinney]

> -Original Message-
> From: gaoliming 
> Sent: Monday, April 12, 2021 6:28 PM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Yao, Jiewen ; Wang, Jian J ; 
> Lu, XiaoyuX ; Jiang,
> Guomin ; Liu, Zhiguang ; 
> Feng, Bob C ; Chen,
> Christine ; 'Andrew Fish' ; 'Abner 
> Chang' 
> Subject: 回复: [edk2-devel] [Patch 0/3] Remove fixed CPU architecture list 
> assumptions
> 
> Mike:
>   Is this update for new ARCH support? With this patch set, new ARCH support
> doesn't need to modify BaseTools. Right?

Correct

> 
>   For this patch set 3/3 BaseTools/Source, I may suggest to split it to two
> patches, one is for C tools, another is for Python tools.

I agree.  I will send V2.

> 
>   For other patch, they are good to me. Reviewed-by: Liming Gao
> 
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Michael D
> > Kinney
> > 发送时间: 2021年4月8日 14:33
> > 收件人: devel@edk2.groups.io
> > 抄送: Jiewen Yao ; Jian J Wang
> > ; Xiaoyu Lu ; Guomin Jiang
> > ; Liming Gao ;
> > Zhiguang Liu ; Bob Feng ;
> > Yuwei Chen ; Andrew Fish ;
> > Abner Chang 
> > 主题: [edk2-devel] [Patch 0/3] Remove fixed CPU architecture list
> > assumptions
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3308
> >
> > The EDK II Build Specifications do not restrict the set of
> > CPU architectures that can be supported.  Remove places in
> > the EDK II that assume a fixed set of CPU architectures.
> >
> > Remove build breaks in the following tools and DEFINES when a check
> against
> > a fixed set of CPU architectures is made.
> >
> > * Build
> > * GenFds
> > * TargetTool
> > * GenFw
> > * SIXTY_FOUR_BIT and THIRTY_TWO_BIT
> > * EFI_IMAGE_MACHINE_TYPE_SUPPORTED
> > * EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED
> > * EFI_REMOVABLE_MEDIA_FILE_NAME
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Xiaoyu Lu Cc
> > Cc: Guomin Jiang 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Bob Feng 
> > Cc: Yuwei Chen 
> > Cc: Andrew Fish 
> > Cc: Abner Chang 
> > Signed-off-by: Michael D Kinney 
> >
> > Michael D Kinney (3):
> >   MdePkg/Include: Allow CPU specific defines to be predefined
> >   CryptoPkg/Library/Include: Allow CPU specific defines to be predefined
> >   BaseTools/Source: Remove CPU architecture assumptions
> >
> >  BaseTools/Source/C/GenFw/Elf32Convert.c  | 5 ++---
> >  BaseTools/Source/C/GenFw/Elf64Convert.c  | 5 ++---
> >  BaseTools/Source/Python/GenFds/FdfParser.py  | 4 +---
> >  BaseTools/Source/Python/TargetTool/TargetTool.py | 4 ++--
> >  BaseTools/Source/Python/build/buildoptions.py| 4 ++--
> >  CryptoPkg/Library/Include/CrtLibSupport.h| 2 ++
> >  MdePkg/Include/Uefi/UefiBaseType.h   | 4 +++-
> >  MdePkg/Include/Uefi/UefiSpec.h   | 4 +++-
> >  8 files changed, 17 insertions(+), 15 deletions(-)
> >
> > --
> > 2.31.1.windows.1
> >
> >
> >
> > 
> >
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74008): https://edk2.groups.io/g/devel/message/74008
Mute This Topic: https://groups.io/mt/82056247/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] MdePkg/Include: Allow CPU specific defines to be predefined

[Michael D Kinney]

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist) 
> Sent: Monday, April 12, 2021 6:57 PM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Liming Gao ; Liu, Zhiguang 
> ; Andrew Fish 
> Subject: RE: [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be 
> predefined
> 
> 
> 
> > -Original Message-
> > From: Michael D Kinney [mailto:michael.d.kin...@intel.com]
> > Sent: Thursday, April 8, 2021 2:33 PM
> > To: devel@edk2.groups.io
> > Cc: Liming Gao ; Zhiguang Liu
> > ; Andrew Fish ; Chang, Abner
> > (HPS SW/FW Technologist) 
> > Subject: [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be
> > predefined
> >
> > REF:
> > https://urldefense.com/v3/__https://bugzilla.tianocore.org/show_bug.cgi?i
> > d=3308__;!!NpxR!2tD2XaYHZQmaFB9Nkxl0iin7W5JxSmdDV0VxeaVsY76lOFR
> > nfql_W6kvYXu66fA$
> >
> > The EDK II Build Specifications do not restrict the set of
> > CPU architectures that can be supported.  Remove places in
> > the EDK II that assume a fixed set of CPU architectures.
> >
> > Update the following 3 DEFINES to allow them to be predefined
> > on the EDK II build command line using /D flags or in DSC file
> > [BuildOptions] sections.
> >
> > * EFI_IMAGE_MACHINE_TYPE_SUPPORTED
> > * EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED
> > * EFI_REMOVABLE_MEDIA_FILE_NAME
> >
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Andrew Fish 
> > Cc: Abner Chang 
> > Signed-off-by: Michael D Kinney 
> > ---
> >  MdePkg/Include/Uefi/UefiBaseType.h | 4 +++-
> >  MdePkg/Include/Uefi/UefiSpec.h | 4 +++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> > b/MdePkg/Include/Uefi/UefiBaseType.h
> > index 934fc07285d9..92ffeb4c63d5 100644
> > --- a/MdePkg/Include/Uefi/UefiBaseType.h
> > +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> > @@ -1,7 +1,7 @@
> >  /** @file
> >Defines data types and constants introduced in UEFI.
> >
> > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > +Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
> >  Portions copyright (c) 2011 - 2016, ARM Ltd. All rights reserved.
> >  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> > reserved.
> >
> > @@ -248,6 +248,7 @@ typedef union {
> >  #define EFI_IMAGE_MACHINE_RISCV64   0x5064
> >  #define EFI_IMAGE_MACHINE_RISCV128  0x5128
> >
> > +#if !defined(EFI_IMAGE_MACHINE_TYPE_SUPPORTED)
> What if EFI_IMAGE_MACHINE_TYPE_SUPPORTED is predefined in /D but 
> EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED is not?
> Throw a warning message or just fix it when build error happens?
> 
> Abner
> 

I was thinking a build error when it is referenced would be sufficient.

The other option is to generate an immediate #error if only one of the two are 
predefined.

> >  #if   defined (MDE_CPU_IA32)
> >
> >  #define EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) \
> > @@ -294,5 +295,6 @@ typedef union {
> >  #else
> >  #error Unknown Processor Type
> >  #endif
> > +#endif
> >
> >  #endif
> > diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> > b/MdePkg/Include/Uefi/UefiSpec.h
> > index 2b1b72d86286..8aeaebc44fd8 100644
> > --- a/MdePkg/Include/Uefi/UefiSpec.h
> > +++ b/MdePkg/Include/Uefi/UefiSpec.h
> > @@ -5,7 +5,7 @@
> >If a code construct is defined in the UEFI 2.7 specification it must be
> > included
> >by this include file.
> >
> > -Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > +Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
> >  Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
> > rights reserved.
> >
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> > @@ -2211,6 +2211,7 @@ typedef struct {
> >  #define EFI_REMOVABLE_MEDIA_FILE_NAME_AARCH64
> > L"\\EFI\\BOOT\\BOOTAA64.EFI"
> >  #define EFI_REMOVABLE_MEDIA_FILE_NAME_RISCV64
> > L"\\EFI\\BOOT\\BOOTRISCV64.EFI"
> >
> > +#if !defined(EFI_REMOVABLE_MEDIA_FILE_NAME)
> >  #if   defined (MDE_CPU_IA32)
> >#define EFI_REMOVABLE_MEDIA_FILE_NAME
> > EFI_REMOVABLE_MEDIA_FILE_NAME_IA32
> >  #elif defined (MDE_CPU_X64)
> > @@ -2225,6 +2226,7 @@ typedef struct {
> >  #else
> >#error Unknown Processor Type
> >  #endif
> > +#endif
> >
> >  //
> >  // The directory within the active EFI System Partition defined for 
> > delivery of
> > capsule to firmware
> > --
> > 2.31.1.windows.1
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74007): https://edk2.groups.io/g/devel/message/74007
Mute This Topic: https://groups.io/mt/81936016/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 00/10] Added support for FT2000/4 chip

[Ling Jia]

Hi Leif,

It's been a few days since I sent V3 patches. Do you have any suggestions for 
this patches? Looking forward to your reply！

Best Regards,

Ling
> -原始邮件-
> 发件人: "Ling Jia" 
> 发送时间: 2021-03-17 15:26:37 (星期三)
> 收件人: devel@edk2.groups.io
> 抄送: "Leif Lindholm" , "Ling Jia" 
> 主题: [PATCH v3 00/10] Added support for FT2000/4 chip
> 
> This series added packages to support FT2000/4 chip.
> Platform/Phytium: Added DurianPkg, include DurianPkg.dsc and DurianPkg.fdf.
> Silicon/Phytium: Added FT2000-4Pkg and PhytiumCommonPkg.
> 
> The modules could be runed at the silicon of FT2000/4.
> They supported Acpi parameter configuration, Pci bus scaning,
> flash read-write and erase abd operating system boot function.
> Maintainers.txt: Added maintainers and reviewers for the DurianPkg.
> 
> The public git repository is :
> https://github.com/jialing2020/edk2-platforms/tree/Phytium_Opensource_For_FT2000-4_v3
> 
> v3:
> Optimized the codes to meet the edk2 coding  specification.
> 
> Ling Jia (10):
>   Silicon/Phytium: Added PlatformLib to FT2000/4
>   Silicon/Phytium: Added Acpi support to FT2000/4
>   Silicon/Phytium: Added SMBIOS support to FT2000/4
>   Silicon/Phytium: Added PciSegmentLib to FT2000/4
>   Silicon/Phytium: Added PciHostBridgeLib to FT2000/4
>   Silicon/Phytium: Added Spi driver support to FT2000/4
>   Silicon/Phytium: Added flash driver support to Phytium Silicon
>   Silicon/Phytium: Added fvb driver for norflash
>   Silicon/Phytium: Added Rtc driver to FT2000/4
>   Maintainers.txt: Added maintainers and reviewers for the DurianPkg
> 
>  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
>|   52 +
>  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
>|  345 +
>  Platform/Phytium/DurianPkg/DurianPkg.dsc 
>|  331 +
>  Platform/Phytium/DurianPkg/DurianPkg.fdf 
>|  235 
>  Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/AcpiTables.inf
>|   56 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf  
>|   47 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
>|   44 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
>|   48 +
>  Silicon/Phytium/FT2000-4Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
>|   47 +
>  Silicon/Phytium/FT2000-4Pkg/Library/PciSegmentLib/PciSegmentLib.inf  
>|   28 +
>  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf  
>|   55 +
>  Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.inf
>|   39 +
>  Silicon/Phytium/PhytiumCommonPkg/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf 
>|   53 +
>  Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf 
>|   61 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h  
>|   64 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.h  
>|   99 ++
>  Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.h  
>|   24 +
>  Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h   
>|  104 ++
>  Silicon/Phytium/PhytiumCommonPkg/Include/Platform.h  
>|   80 ++
>  Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiNorFlashProtocol.h  
>|   74 +
>  Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiProtocol.h  
>|   51 +
>  Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h
>|  112 ++
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
>|  943 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c  
>|  198 +++
>  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.c  
>|  424 ++
>  Silicon/Phytium/FT2000-4Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c  
>|  181 +++
>  Silicon/Phytium/FT2000-4Pkg/Library/PciSegmentLib/PciSegmentLib.c
>| 1434 
>  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c
>|  137 ++
>  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c 
>|  156 +++
>  Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c  
>|  462 +++
>  Silicon/Phytium/PhytiumCommonPkg/Drivers/AcpiPlatformDxe/AcpiPlatform.c  
>|  250 
>  Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.c   
>| 1304 ++
>  Maintainers.txt  
>|8 +
>  Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/AcpiSsdtRootPci.asl   
>|  209 +++
>  Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dbg2.aslc 
>|   80 ++
>  

Re: [edk2-devel] [Patch 3/3] BaseTools/Source: Remove CPU architecture assumptions

[Abner Chang]

> -Original Message-
> From: Michael D Kinney [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, April 8, 2021 2:33 PM
> To: devel@edk2.groups.io
> Cc: Bob Feng ; Liming Gao
> ; Yuwei Chen ;
> Andrew Fish ; Chang, Abner (HPS SW/FW Technologist)
> 
> Subject: [Patch 3/3] BaseTools/Source: Remove CPU architecture
> assumptions
> 
> REF:
> INVALID URI REMOVED
> d=3308__;!!NpxR!y1a0Mm0__hLCGUN_tBqH8jshZ_739mOBXcCvlT6o_WQKy
> YICmQVJg5Wjl1Gr4vc$
> 
> The EDK II Build Specifications do not restrict the set of
> CPU architectures that can be supported.  Remove places in
> the EDK II that assume a fixed set of CPU architectures.
> 
> Remove build breaks in the following tools when a check against
> a fixed set of CPU architectures is made.
> 
> * Build
> * GenFds
> * TargetTool
> * GenFw
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yuwei Chen 
> Cc: Andrew Fish 
> Cc: Abner Chang 
> Signed-off-by: Michael D Kinney 
> ---
>  BaseTools/Source/C/GenFw/Elf32Convert.c  | 5 ++---
>  BaseTools/Source/C/GenFw/Elf64Convert.c  | 5 ++---
>  BaseTools/Source/Python/GenFds/FdfParser.py  | 4 +---
>  BaseTools/Source/Python/TargetTool/TargetTool.py | 4 ++--
>  BaseTools/Source/Python/build/buildoptions.py| 4 ++--
>  5 files changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c
> b/BaseTools/Source/C/GenFw/Elf32Convert.c
> index 7f351287a93c..2485b2cb7ad9 100644
> --- a/BaseTools/Source/C/GenFw/Elf32Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Elf32 Convert solution
> 
> -Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2010 - 2021, Intel Corporation. All rights reserved.
>  Portions copyright (c) 2013, ARM Ltd. All rights reserved.
>  Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> 
> @@ -143,8 +143,7 @@ InitializeElf32 (
>  return FALSE;
>}
>if (!((mEhdr->e_machine == EM_386) || (mEhdr->e_machine == EM_ARM)
> || (mEhdr->e_machine == EM_RISCV))) {
> -Error (NULL, 0, 3000, "Unsupported", "ELF e_machine is not Elf32
> machine.");
> -return FALSE;
> +Warning (NULL, 0, 3000, "Unsupported", "ELF e_machine is not Elf32
> machine.");
>}
>if (mEhdr->e_version != EV_CURRENT) {
>  Error (NULL, 0, 3000, "Unsupported", "ELF e_version (%u) not
> EV_CURRENT (%d)", (unsigned) mEhdr->e_version, EV_CURRENT);
> diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> index 4ed6b4477ea9..d097db863243 100644
> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Elf64 convert solution
> 
> -Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2010 - 2021, Intel Corporation. All rights reserved.
>  Portions copyright (c) 2013-2014, ARM Ltd. All rights reserved.
>  Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> 
> @@ -162,8 +162,7 @@ InitializeElf64 (
>  return FALSE;
>}
>if (!((mEhdr->e_machine == EM_X86_64) || (mEhdr->e_machine ==
> EM_AARCH64) || (mEhdr->e_machine == EM_RISCV64))) {
> -Error (NULL, 0, 3000, "Unsupported", "ELF e_machine is not Elf64
> machine.");
> -return FALSE;
> +Warning (NULL, 0, 3000, "Unsupported", "ELF e_machine is not Elf64
> machine.");
>}
>if (mEhdr->e_version != EV_CURRENT) {
>  Error (NULL, 0, 3000, "Unsupported", "ELF e_version (%u) not
> EV_CURRENT (%d)", (unsigned) mEhdr->e_version, EV_CURRENT);
> diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
> b/BaseTools/Source/Python/GenFds/FdfParser.py
> index ea2401b0e4fc..5c8263f9bcc9 100644
> --- a/BaseTools/Source/Python/GenFds/FdfParser.py
> +++ b/BaseTools/Source/Python/GenFds/FdfParser.py
> @@ -1,7 +1,7 @@
>  ## @file
>  # parse FDF file
>  #
> -#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2015, Hewlett Packard Enterprise Development, L.P.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -3504,8 +3504,6 @@ class FdfParser:
>  raise Warning.Expected("'.'", self.FileName, 
> self.CurrentLineNumber)
> 
>  Arch = self._SkippedChars.rstrip(TAB_SPLIT)
> -if Arch.upper() not in ARCH_SET_FULL:
> -raise Warning("Unknown Arch '%s'" % Arch, self.FileName,
> self.CurrentLineNumber)
> 
>  ModuleType = self._GetModuleType()
> 
> diff --git a/BaseTools/Source/Python/TargetTool/TargetTool.py
> b/BaseTools/Source/Python/TargetTool/TargetTool.py
> index 8e0ca387c356..71222e3cc899 100644
> --- a/BaseTools/Source/Python/TargetTool/TargetTool.py
> +++ b/BaseTools/Source/Python/TargetTool/TargetTool.py
> @@ -1,7 +1,7 @@
>  ## @file
>  # Target Tool Parser
>  #
> -#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> 

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg/Tcg2Smm: Initialize local Status variable

[Wang, Jian J]

Pushed @ 54211ab10fcd8532b49f4024ebdb601a8eb07e3e

Regards,
Jian

> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, April 13, 2021 1:54 AM
> To: devel@edk2.groups.io; ler...@redhat.com
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 ;
> Kun Qin 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg/Tcg2Smm: Initialize local
> Status variable
> 
> Hi Laszlo and SecurityPkg maintainers,
> 
> This is a relatively straightforward patch. Please let me know if
> anything else is needed for you to submit it.
> 
> Thanks,
> Michael
> 
> On 4/7/2021 9:06 AM, Laszlo Ersek wrote:
> > On 04/06/21 20:12, mikub...@linux.microsoft.com wrote:
> >> From: Michael Kubacki 
> >>
> >> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3277
> >>
> >> Initializes the Status variable in TcgMmReadyToLock().
> >>
> >> Fixes a Clang build failure:
> >> Tcg2Smm.c - SecurityPkg\Tcg\Tcg2Smm\Tcg2Smm.c:254:7: error:
> >> variable 'Status' is used uninitialized whenever 'if'
> >> condition is false [-Werror,-Wsometimes-uninitialized]
> >>
> >> Initializing this variable is required to address a practical
> >> scenario in which the return value of TcgMmReadyToLock() is
> >> undefined based on conditional evaluation in the function.
> >>
> >> Cc: Jiewen Yao 
> >> Cc: Jian J Wang 
> >> Cc: Qi Zhang 
> >> Cc: Rahul Kumar 
> >> Cc: Kun Qin 
> >> Signed-off-by: Michael Kubacki 
> >> Reviewed-by: Jiewen Yao 
> >> ---
> >>
> >> Notes:
> >>  V2 change:
> >>
> >>  Clarify in commit message that the issue reported by Clang is not
> >>  solely a false positive.
> >>
> >>   SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> >> index 589c08794bcf..f49eccb0bdf4 100644
> >> --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> >> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> >> @@ -253,6 +253,8 @@ TcgMmReadyToLock (
> >>   {
> >> EFI_STATUS Status;
> >>
> >> +  Status = EFI_SUCCESS;
> >> +
> >> if (mReadyToLockHandle != NULL) {
> >>   Status = gMmst->MmiHandlerUnRegister (mReadyToLockHandle);
> >>   mReadyToLockHandle = NULL;
> >>
> >
> > Awesome, thanks!
> >
> > I've also managed to look at the code now.
> >
> > Reviewed-by: Laszlo Ersek 
> >
> > Thanks
> > Laszlo
> >
> >
> >
> > 
> >


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

Re: [edk2-devel] [Patch 2/3] CryptoPkg/Library/Include: Allow CPU specific defines to be predefined

[Abner Chang]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Michael D Kinney [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, April 8, 2021 2:33 PM
> To: devel@edk2.groups.io
> Cc: Jiewen Yao ; Jian J Wang
> ; Xiaoyu Lu ; Guomin Jiang
> ; Andrew Fish ; Chang, Abner
> (HPS SW/FW Technologist) 
> Subject: [Patch 2/3] CryptoPkg/Library/Include: Allow CPU specific defines to
> be predefined
> 
> REF:
> INVALID URI REMOVED
> d=3308__;!!NpxR!2-P3Y-
> hszCTVv28TDqqSG3TmDAWbHH_z7uQuHZYnM4_Gf5ueOE8v4f32Jklssow$
> 
> The EDK II Build Specifications do not restrict the set of
> CPU architectures that can be supported.  Remove places in
> the EDK II that assume a fixed set of CPU architectures.
> 
> Update SIXTY_FOUR_BIT and THIRTY_TWO_BIT defines in the
> CryptoPkg to allow one of them to be predefined on the EDK II
> build command line using /D flag or in DSC file [BuildOptions]
> sections.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Cc: Guomin Jiang 
> Cc: Andrew Fish 
> Cc: Abner Chang 
> Signed-off-by: Michael D Kinney 
> ---
>  CryptoPkg/Library/Include/CrtLibSupport.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/CryptoPkg/Library/Include/CrtLibSupport.h
> b/CryptoPkg/Library/Include/CrtLibSupport.h
> index 7a82f1d40633..a7d9a768695a 100644
> --- a/CryptoPkg/Library/Include/CrtLibSupport.h
> +++ b/CryptoPkg/Library/Include/CrtLibSupport.h
> @@ -44,6 +44,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #define CONFIG_HEADER_BN_H
> 
> +#if !defined(SIXTY_FOUR_BIT) && !defined (THIRTY_TWO_BIT)
>  #if defined(MDE_CPU_X64) || defined(MDE_CPU_AARCH64) ||
> defined(MDE_CPU_IA64) || defined(MDE_CPU_RISCV64)
>  //
>  // With GCC we would normally use SIXTY_FOUR_BIT_LONG, but MSVC
> needs
> @@ -56,6 +57,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #else
>  #error Unknown target architecture
>  #endif
> +#endif
> 
>  //
>  // Map all va_ elements to VA_xxx defined in MdePkg/Include/Base.h
> --
> 2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74003): https://edk2.groups.io/g/devel/message/74003
Mute This Topic: https://groups.io/mt/81936018/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] MdePkg/Include: Allow CPU specific defines to be predefined

[Abner Chang]

> -Original Message-
> From: Michael D Kinney [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, April 8, 2021 2:33 PM
> To: devel@edk2.groups.io
> Cc: Liming Gao ; Zhiguang Liu
> ; Andrew Fish ; Chang, Abner
> (HPS SW/FW Technologist) 
> Subject: [Patch 1/3] MdePkg/Include: Allow CPU specific defines to be
> predefined
> 
> REF:
> INVALID URI REMOVED
> d=3308__;!!NpxR!2tD2XaYHZQmaFB9Nkxl0iin7W5JxSmdDV0VxeaVsY76lOFR
> nfql_W6kvYXu66fA$
> 
> The EDK II Build Specifications do not restrict the set of
> CPU architectures that can be supported.  Remove places in
> the EDK II that assume a fixed set of CPU architectures.
> 
> Update the following 3 DEFINES to allow them to be predefined
> on the EDK II build command line using /D flags or in DSC file
> [BuildOptions] sections.
> 
> * EFI_IMAGE_MACHINE_TYPE_SUPPORTED
> * EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED
> * EFI_REMOVABLE_MEDIA_FILE_NAME
> 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Andrew Fish 
> Cc: Abner Chang 
> Signed-off-by: Michael D Kinney 
> ---
>  MdePkg/Include/Uefi/UefiBaseType.h | 4 +++-
>  MdePkg/Include/Uefi/UefiSpec.h | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> b/MdePkg/Include/Uefi/UefiBaseType.h
> index 934fc07285d9..92ffeb4c63d5 100644
> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> @@ -1,7 +1,7 @@
>  /** @file
>Defines data types and constants introduced in UEFI.
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
>  Portions copyright (c) 2011 - 2016, ARM Ltd. All rights reserved.
>  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> 
> @@ -248,6 +248,7 @@ typedef union {
>  #define EFI_IMAGE_MACHINE_RISCV64   0x5064
>  #define EFI_IMAGE_MACHINE_RISCV128  0x5128
> 
> +#if !defined(EFI_IMAGE_MACHINE_TYPE_SUPPORTED)
What if EFI_IMAGE_MACHINE_TYPE_SUPPORTED is predefined in /D but 
EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED is not?
Throw a warning message or just fix it when build error happens?

Abner

>  #if   defined (MDE_CPU_IA32)
> 
>  #define EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) \
> @@ -294,5 +295,6 @@ typedef union {
>  #else
>  #error Unknown Processor Type
>  #endif
> +#endif
> 
>  #endif
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h
> index 2b1b72d86286..8aeaebc44fd8 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -5,7 +5,7 @@
>If a code construct is defined in the UEFI 2.7 specification it must be
> included
>by this include file.
> 
> -Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
>  Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -2211,6 +2211,7 @@ typedef struct {
>  #define EFI_REMOVABLE_MEDIA_FILE_NAME_AARCH64
> L"\\EFI\\BOOT\\BOOTAA64.EFI"
>  #define EFI_REMOVABLE_MEDIA_FILE_NAME_RISCV64
> L"\\EFI\\BOOT\\BOOTRISCV64.EFI"
> 
> +#if !defined(EFI_REMOVABLE_MEDIA_FILE_NAME)
>  #if   defined (MDE_CPU_IA32)
>#define EFI_REMOVABLE_MEDIA_FILE_NAME
> EFI_REMOVABLE_MEDIA_FILE_NAME_IA32
>  #elif defined (MDE_CPU_X64)
> @@ -2225,6 +2226,7 @@ typedef struct {
>  #else
>#error Unknown Processor Type
>  #endif
> +#endif
> 
>  //
>  // The directory within the active EFI System Partition defined for delivery 
> of
> capsule to firmware
> --
> 2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74002): https://edk2.groups.io/g/devel/message/74002
Mute This Topic: https://groups.io/mt/81936016/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, 04/13/2021 6:30pm-7:30pm #cal-reminder

[gaoliming]

Hi, all

 The following issues will be discussed on this week Bug Triage meeting. And, 
this week meeting will use Teams. Please get the meeting information from 
https://edk2.groups.io/g/devel/calendar.

 


  3300

EDK2

Code

unassig...@tianocore.org

UNCO

Physical Address Bits in PiSmmCpuDxeSmm updated during SetStaticPageTable 
routine  

19:13:30

kun@microsoft.com


  3331

EDK2

Code

unassig...@tianocore.org

UNCO

Treat memory protection attributes separately 
 

12:34:52

mhaeu...@posteo.de


  3329

EDK2

Code

unassig...@tianocore.org

UNCO

DxeCore: No support for granular PE section permissions 
 

11:26:30

mhaeu...@posteo.de


  3327

EDK2

Code

unassig...@tianocore.org

UNCO

DxeCore: Image-based MAT splitting may emit unintended permissions 
 

11:16:47

mhaeu...@posteo.de


  3326

EDK2

Code

unassig...@tianocore.org

UNCO

Enforce W^X design principles 
 

10:42:23

mhaeu...@posteo.de


  3325

EDK2

Code

unassig...@tianocore.org

UNCO

AsmReadMsr64() for the GCC toolchain can return uninitialized value 
 

10:39:38

nait...@gmail.com


  3323

EDK2

Code

unassig...@tianocore.org

UNCO

LoadFile: Insufficient data is returned 
 

10:20:16

mhaeu...@posteo.de


  3321

EDK2

Code

unassig...@tianocore.org

UNCO

PiPeiCis: Section data returned without corresponding size 
 

09:56:58

mhaeu...@posteo.de


  3319

EDK2

Code

unassig...@tianocore.org

UNCO

MpInitLib/Dxe: BackupBuffer and WakeupBufferHigh have been deprecated 
 

09:46:23

mhaeu...@posteo.de


  3318

EDK2

Code

unassig...@tianocore.org

UNCO

Inconsistency between .rdata and .rodata sections 
 

09:38:19

mhaeu...@posteo.de


  3315

EDK2

Code

unassig...@tianocore.org

UNCO

DxeCore: Unloading image pre-CpuDxe may dereference NULL 
 

09:12:33

mhaeu...@posteo.de


  3314

Tianocor

Code

unassig...@tianocore.org

UNCO

Add support for RSASSA-PSS signature scheme in Crypto package 
 

Fri 18:55

sachin.agra...@intel.com


  3305

EDK2

Code

unassig...@tianocore.org

UNCO

FreePool : Exploitable if Buffer does not belong to SMRAM. SMM should always 
call Smst version not gBS version 
 

Fri 10:01

sunil.i.dodam...@intel.com


  3311

EDK2

Code

unassig...@tianocore.org

UNCO

SetupBrowserDxe does not handle two formsets using the same VarStoreID 
 

Thu 17:36

allen_w...@dell.com


  3307

EDK2 Pla

MinPlatf

michael.kuba...@microsoft.com

UNCO

Cleanup and consolidate SpiFlashCommonLib instances 
 

Wed 15:03

michael.kuba...@microsoft.com


  3302

EDK2

Tools

unassig...@tianocore.org

UNCO

BaseTools can't be built on Windows because warnings are set to error 
 

2021-04-06

harlydavid...@gmail.com


  3299

EDK2

Code

unassig...@tianocore.org

UNCO

[BaseTools] GenFw: Unsupported ELF EM_RISCV64 relocations 0x13 and 0x14 
 

2021-04-06

p...@akeo.ie


  3296

EDK2

Code

unassig...@tianocore.org

UNCO

EFI_ACPI_MAX_NUM_TABLES hardcoded to 20 was too small for our platform. 
 

2021-04-06

af...@apple.com


  3298

EDK2 Pla

MinPlatf

unassig...@tianocore.org

UNCO

回复: [edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS and MAKE_PATH fixes

[gaoliming]

Mike:
  I don't see the issue in the code change. I want to know what unit test
has been done for this change. 

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Michael D
> Kinney
> 发送时间: 2021年4月10日 5:49
> 收件人: devel@edk2.groups.io
> 抄送: Bob Feng ; Liming Gao
> ; Yuwei Chen 
> 主题: [edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS
> and MAKE_PATH fixes
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3312
> 
> Update parsing of MAKE_FLAGS in DSC [BuildOptions] sections
> to split the flags into a list to be compatible with
> running the make command using Popen().  Parsing MAKE_FLAGS
> from tools_def.txt already uses _SplitOption().  This change
> uses the same _SplitOption() method for MAKE_FLAGS from a
> DSC [BuildOptions] section.
> 
> Also update the parsing of MAKE_PATH to support MAKE_PATH
> from tools_def.txt or the DSC [BuildOptions] section.  MAKE_PATH
> in DSC [BuildOptions] section is higher priority than MAKE_PATH
> in tools_def.txt.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yuwei Chen 
> Signed-off-by: Michael D Kinney 
> ---
>  .../Source/Python/AutoGen/PlatformAutoGen.py  | 36 +++
>  1 file changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> index 7d8e7b3c7cc1..c16f2e4cd8b7 100644
> --- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> @@ -1,7 +1,7 @@
>  ## @file
>  # Create makefile for MS nmake and GNU make
>  #
> -# Copyright (c) 2019, Intel Corporation. All rights reserved.
> +# Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2020, ARM Limited. All rights reserved.
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -805,20 +805,26 @@ class PlatformAutoGen(AutoGen):
>  #
>  @cached_property
>  def BuildCommand(self):
> -RetVal = []
> -if "MAKE" in self.ToolDefinition and "PATH" in
> self.ToolDefinition["MAKE"]:
> -RetVal += _SplitOption(self.ToolDefinition["MAKE"]["PATH"])
> -if "FLAGS" in self.ToolDefinition["MAKE"]:
> -NewOption =
> self.ToolDefinition["MAKE"]["FLAGS"].strip()
> -if NewOption != '':
> -RetVal += _SplitOption(NewOption)
> -if "MAKE" in self.EdkIIBuildOption:
> -if "FLAGS" in self.EdkIIBuildOption["MAKE"]:
> -Flags = self.EdkIIBuildOption["MAKE"]["FLAGS"]
> -if Flags.startswith('='):
> -RetVal = [RetVal[0]] + [Flags[1:]]
> -else:
> -RetVal.append(Flags)
> +if "MAKE" in self.EdkIIBuildOption and "PATH" in
> self.EdkIIBuildOption["MAKE"]:
> +# MAKE_PATH in DSC [BuildOptions] section is higher priority
> +Path = self.EdkIIBuildOption["MAKE"]["PATH"]
> +if Path.startswith('='):
> +Path = Path[1:].strip()
> +RetVal = _SplitOption(Path)
> +elif "MAKE" in self.ToolDefinition and "PATH" in
> self.ToolDefinition["MAKE"]:
> +RetVal = _SplitOption(self.ToolDefinition["MAKE"]["PATH"])
> +else:
> +return []
> +if "MAKE" in self.ToolDefinition and "FLAGS" in
> self.ToolDefinition["MAKE"]:
> +NewOption = self.ToolDefinition["MAKE"]["FLAGS"].strip()
> +if NewOption != '':
> +RetVal += _SplitOption(NewOption)
> +if "MAKE" in self.EdkIIBuildOption and "FLAGS" in
> self.EdkIIBuildOption["MAKE"]:
> +Flags = self.EdkIIBuildOption["MAKE"]["FLAGS"]
> +if Flags.startswith('='):
> +RetVal = [RetVal[0]] + _SplitOption(Flags[1:].strip())
> +else:
> +RetVal = RetVal + _SplitOption(Flags.strip())
>  return RetVal
> 
>  ## Get tool chain definition
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74000): https://edk2.groups.io/g/devel/message/74000
Mute This Topic: https://groups.io/mt/82055086/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, 04/13/2021 6:30pm-7:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Tuesday, 13 April 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
Angeles

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

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

*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 (#73999): https://edk2.groups.io/g/devel/message/73999
Mute This Topic: https://groups.io/mt/82055058/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]
-=-=-=-=-=-=-=-=-=-=-=-

回复: [edk2-devel] [Patch 0/3] Remove fixed CPU architecture list assumptions

[gaoliming]

Mike:
  Is this update for new ARCH support? With this patch set, new ARCH support
doesn't need to modify BaseTools. Right? 

  For this patch set 3/3 BaseTools/Source, I may suggest to split it to two
patches, one is for C tools, another is for Python tools. 

  For other patch, they are good to me. Reviewed-by: Liming Gao


Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Michael D
> Kinney
> 发送时间: 2021年4月8日 14:33
> 收件人: devel@edk2.groups.io
> 抄送: Jiewen Yao ; Jian J Wang
> ; Xiaoyu Lu ; Guomin Jiang
> ; Liming Gao ;
> Zhiguang Liu ; Bob Feng ;
> Yuwei Chen ; Andrew Fish ;
> Abner Chang 
> 主题: [edk2-devel] [Patch 0/3] Remove fixed CPU architecture list
> assumptions
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3308
> 
> The EDK II Build Specifications do not restrict the set of
> CPU architectures that can be supported.  Remove places in
> the EDK II that assume a fixed set of CPU architectures.
> 
> Remove build breaks in the following tools and DEFINES when a check
against
> a fixed set of CPU architectures is made.
> 
> * Build
> * GenFds
> * TargetTool
> * GenFw
> * SIXTY_FOUR_BIT and THIRTY_TWO_BIT
> * EFI_IMAGE_MACHINE_TYPE_SUPPORTED
> * EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED
> * EFI_REMOVABLE_MEDIA_FILE_NAME
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu Cc
> Cc: Guomin Jiang 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Bob Feng 
> Cc: Yuwei Chen 
> Cc: Andrew Fish 
> Cc: Abner Chang 
> Signed-off-by: Michael D Kinney 
> 
> Michael D Kinney (3):
>   MdePkg/Include: Allow CPU specific defines to be predefined
>   CryptoPkg/Library/Include: Allow CPU specific defines to be predefined
>   BaseTools/Source: Remove CPU architecture assumptions
> 
>  BaseTools/Source/C/GenFw/Elf32Convert.c  | 5 ++---
>  BaseTools/Source/C/GenFw/Elf64Convert.c  | 5 ++---
>  BaseTools/Source/Python/GenFds/FdfParser.py  | 4 +---
>  BaseTools/Source/Python/TargetTool/TargetTool.py | 4 ++--
>  BaseTools/Source/Python/build/buildoptions.py| 4 ++--
>  CryptoPkg/Library/Include/CrtLibSupport.h| 2 ++
>  MdePkg/Include/Uefi/UefiBaseType.h   | 4 +++-
>  MdePkg/Include/Uefi/UefiSpec.h   | 4 +++-
>  8 files changed, 17 insertions(+), 15 deletions(-)
> 
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 





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

回复: [edk2-devel] [PATCH v1 1/1] Fix AsmReadMsr64() and AsmWriteMsr64() with GCC toolchain

[gaoliming]

Naito:
  The fix is correct. Reviewed-by: Liming Gao 

Thanks
Liming 
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Takuto Naito
> 发送时间: 2021年4月12日 23:07
> 收件人: devel@edk2.groups.io
> 抄送: Takuto Naito ; Michael D Kinney
> ; Liming Gao ;
> Zhiguang Liu 
> 主题: [edk2-devel] [PATCH v1 1/1] Fix AsmReadMsr64() and AsmWriteMsr64()
> with GCC toolchain
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3325
> 
> 1. AsmReadMsr64() in X64/GccInlinePriv.c
> AsmReadMsr64 can return uninitialized value if FilterBeforeMsrRead
> returns False. This causes build error with the CLANG toolchain.
> 
> 2. AsmWriteMsr64() in X64/GccInlinePriv.c
> In the case that FilterBeforeMsrWrite changes Value and returns True,
> The original Value, not the changed Value, is written to the MSR.
> This behavior is different from the one of AsmWriteMsr64() in
> X64/WriteMsr64.c for the MSFT toolchain.
> 
> Signed-off-by: Takuto Naito 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Library/BaseLib/X64/GccInlinePriv.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
> b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
> index e4920f2116..244bd62ee6 100644
> --- a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
> +++ b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
> @@ -80,7 +80,7 @@ AsmReadMsr64 (
>}
>FilterAfterMsrRead (Index, );
> 
> -  return (((UINT64)HighData) << 32) | LowData;
> +  return Value;
>  }
> 
>  /**
> @@ -111,11 +111,10 @@ AsmWriteMsr64 (
>UINT32 HighData;
>BOOLEAN Flag;
> 
> -  LowData  = (UINT32)(Value);
> -  HighData = (UINT32)(Value >> 32);
> -
>Flag = FilterBeforeMsrWrite (Index, );
>if (Flag) {
> +LowData  = (UINT32)(Value);
> +HighData = (UINT32)(Value >> 32);
>  __asm__ __volatile__ (
>"wrmsr"
>:
> --
> 2.31.1
> 
> 
> 
> 
> 





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

[edk2-devel] GSoC (Google Summer of Code) Application Deadline Approaching

[Nate DeSimone]

Hi Everyone,

Quick heads up, the GSoC application deadline is 17 hours from now. I still see 
5 applications in draft status. Google is very strict about their deadlines, 
even if you are 1 minute late they won't accept it. Please make sure that all 
applications are submitted and marked as final before 11am Pacific Time 
tomorrow.

Thank you everyone for all the work you have done on your GSoC applications 
thus far! All of you had a lot of great questions and I'm looking forward to 
this upcoming summer!

With Best Regards,
Nate


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

回复: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in VarCheckPolicyLib

[gaoliming]

I create PR https://github.com/tianocore/edk2/pull/1557 for this patch. 

 

发件人: devel@edk2.groups.io  代表 Bret Barkelew via
groups.io
发送时间: 2021年4月13日 0:24
收件人: devel@edk2.groups.io; hao.a...@intel.com; Bret Barkelew

抄送: Wang, Jian J 
主题: Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable
in VarCheckPolicyLib

 

Looks like we have the requisite approvals. Shall I create a PR?

 

- Bret 

 

From: Wu, Hao A via groups.io  
Sent: Sunday, April 11, 2021 7:23 PM
To: Bret Barkelew  ; devel@edk2.groups.io
 
Cc: Wang, Jian J  
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize
temp variable in VarCheckPolicyLib

 

> -Original Message-
> From: Bret Barkelew mailto:b...@corthon.com> >
> Sent: Saturday, April 10, 2021 2:25 AM
> To: devel@edk2.groups.io  
> Cc: Wang, Jian J mailto:jian.j.w...@intel.com> >;
Wu, Hao A mailto:hao.a...@intel.com> >
> Subject: [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in
> VarCheckPolicyLib
> 
> DumpVariablePolicy() will return EFI_INVALID_PARAMETER if the Buffer
> pointer is NULL and the indirect Size is anything but 0. Since this
TempSize
> was not being initialized it is very likely that this sequence would not
return
> the total buffer size as expected.
> 
> Bugzilla:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.t
ianocore.org%2Fshow_bug.cgi%3Fid%3D3310 
data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cdd597013a0874fa676f708d8
fd5a02e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637537910324146700%7CU
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6Mn0%3D%7C1000sdata=qxCQ6vccJFzG8gH9qDBHD9xnl%2FCs3DdVUuMtHspanfY%3
Dreserved=0
> 
> Cc: Jian J Wang mailto:jian.j.w...@intel.com> >
> Cc: Hao A Wu mailto:hao.a...@intel.com> >
> Signed-off-by: Bret Barkelew mailto:bret.barke...@microsoft.com> >
> ---
>  MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> index 14e1904e96d3..e50edb4ffc5a 100644
> --- a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> +++ b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> @@ -216,6 +216,7 @@ VarCheckPolicyLibMmiHandler (
>  DumpParamsOut->TotalSize = 0;
>  DumpParamsOut->PageSize = 0;
>  DumpParamsOut->HasMore = FALSE;
> +TempSize = 0;
>  SubCommandStatus = DumpVariablePolicy (NULL, );


Reviewed-by: Hao A Wu mailto:hao.a...@intel.com> >

Best Regards,
Hao Wu


>  if (SubCommandStatus == EFI_BUFFER_TOO_SMALL && TempSize > 0) {
>mCurrentPaginationCommand =
> VAR_CHECK_POLICY_COMMAND_DUMP;
> --
> 2.28.0.windows.1






 





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

回复: [edk2-devel] [PATCH v3 2/7] MdePkg: Allow PcdFSBClock to by Dynamic

[gaoliming]

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Anthony
> PERARD via groups.io
> 发送时间: 2021年4月12日 21:30
> 收件人: devel@edk2.groups.io
> 抄送: Laszlo Ersek ; Jordan Justen
> ; Ard Biesheuvel ;
> xen-de...@lists.xenproject.org; Anthony PERARD
> ; Julien Grall ; Michael D
> Kinney ; Liming Gao
> ; Zhiguang Liu ; Liming
> Gao 
> 主题: [edk2-devel] [PATCH v3 2/7] MdePkg: Allow PcdFSBClock to by
> Dynamic
> 
> We are going to want to change the value of PcdFSBClock at run time in
> OvmfXen, so move it to the PcdsDynamic section.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Laszlo Ersek 
> Reviewed-by: Liming Gao 
> ---
> 
> Notes:
> CC: Michael D Kinney 
> CC: Liming Gao 
> CC: Zhiguang Liu 
> 
>  MdePkg/MdePkg.dec | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index f4156920e599..8965e903e093 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2265,10 +2265,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule]
># @ValidList  0x8001 | 8, 16, 32
>gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d
> 
> -  ## This value is used to configure X86 Processor FSB clock.
> -  # @Prompt FSB Clock.
> -
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
> -
>## The maximum printable number of characters. UefLib functions:
> AsciiPrint(), AsciiErrorPrint(),
>#  PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD
value to
> print characters.
># @Prompt Maximum Printable Number of Characters.
> @@ -2372,5 +2368,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule,
> PcdsDynamic, PcdsDynamicEx]
># @Prompt Boot Timeout (s)
> 
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x
> 002c
> 
> +  ## This value is used to configure X86 Processor FSB clock.
> +  # @Prompt FSB Clock.
> +
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>MdePkgExtra.uni
> --
> Anthony PERARD
> 
> 
> 
> 
> 





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

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

[Nate DeSimone]

Hi Marvin,

I agree with Mike K that having both the new strict loader and the old loader 
co-exist for some time may be the best option. That will give the ecosystem 
time to test the new loader and correct any issues that arise from its 
introduction.

Best Regards,
Nate

-Original Message-
From: Kinney, Michael D  
Sent: Monday, April 12, 2021 5:20 PM
To: Marvin Häuser ; devel@edk2.groups.io; Desimone, 
Nathaniel L ; Laszlo Ersek ; 
Andrew Fish ; Kinney, Michael D 
Subject: RE: [edk2-devel] [GSoC proposal] Secure Image Loader

Hi Marvin,

If it has not already been considered, one option is to submit a new instance 
of the PE/COFF Library, so both the existing one and the new one are available 
to the ecosystem.

This allows you to be successful in submitting code outlined in your proposal 
and gives the ecosystem time to evaluate and decide when/if to switch from the 
old to the new.

Mike

> -Original Message-
> From: Marvin Häuser 
> Sent: Monday, April 12, 2021 10:22 AM
> To: devel@edk2.groups.io; Desimone, Nathaniel L 
> ; Laszlo Ersek ; 
> Andrew Fish ; Kinney, Michael D 
> 
> Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader
> 
> Good day Nate,
> 
> As you seem to be mostly in charge of the GSoC side of things, I 
> direct this at you, but of course everyone is welcome to comment.
> 
> I think I finished my first round of investigations just in time for 
> the deadline. You can find a list of BZs attached[1]. Please note that 
> 1) some are declared security issues and may not be publicly 
> accessible, and 2) that this list is far from complete. I only added 
> items that are
> a) not implicitly fixed by "simply" deploying the new Image Loader
> (*some* important prerequisites are listed), and b) I am confident are 
> actual issues (or things to consider) I believe to know how to approach.
> 
> I have taken notes about more things, e.g. the existence of the 
> security architectural protocols, which I could not find a rationale 
> for. I can prepare something for this matter, but it really needs an 
> active discussion with some of the core people. I'm not sure delayed 
> e-mail discussion is going to be enough, but there is an official IRC 
> I suppose. :) I hope we can work something out for this.
> 
> I also hope this makes it clearer why I don't believe that we need to 
> "fill" 10 weeks, but rather the opposite. This is not a matter of 
> replacing a library instance, but the whole surrounding ecosystem 
> needs to follow for the changes to make sense. And as I tried to make 
> clear in my discussion with Michael Brown, I am not keen on preserving 
> backwards-compatibility with platform code (i.e. PEI, DXE, things we 
> consider "internal"), as most of it should be controlled by EDK II 
> already. This of course does *not* include user code (OROMs, 
> bootloaders, ...), for which I want to provide the *option* to lock 
> some of them out for security, but with sane defaults that will ensure 
> good compatibility.
> 
> I'd like to thank Michael Brown for his cooperation and support, 
> because we recently landed changes in iPXE to allow for the strictest 
> image format and permission constraints currently possible[2].
> 
> I will have to rework the submitted proposal to reflect the new 
> knowledge. To be honest, seeing how the BZs kept rolling in, I am not 
> convinced an amazing amount of mainlining can be accomplished during 
> the
> 10 weeks. It may have to suffice to have a publicly accessible 
> prototype (e.g. OVMF) and a subset of the planned patches on the list. 
> I hope you can manage to provide some feedback before the deadline passes 
> tomorrow.
> 
> Thank you in advance!
> 
> Best regards,
> Marvin
> 
> [1]
> https://bugzilla.tianocore.org/show_bug.cgi?id=3315
> https://bugzilla.tianocore.org/show_bug.cgi?id=3316
> https://bugzilla.tianocore.org/show_bug.cgi?id=3317
> https://bugzilla.tianocore.org/show_bug.cgi?id=3318
> https://bugzilla.tianocore.org/show_bug.cgi?id=3319
> https://bugzilla.tianocore.org/show_bug.cgi?id=3320
> https://bugzilla.tianocore.org/show_bug.cgi?id=3321
> https://bugzilla.tianocore.org/show_bug.cgi?id=3322
> https://bugzilla.tianocore.org/show_bug.cgi?id=3323
> https://bugzilla.tianocore.org/show_bug.cgi?id=3324
> https://bugzilla.tianocore.org/show_bug.cgi?id=3326
> https://bugzilla.tianocore.org/show_bug.cgi?id=3327
> https://bugzilla.tianocore.org/show_bug.cgi?id=3328
> https://bugzilla.tianocore.org/show_bug.cgi?id=3329
> https://bugzilla.tianocore.org/show_bug.cgi?id=3330
> https://bugzilla.tianocore.org/show_bug.cgi?id=3331
> 
> [2] https://github.com/ipxe/ipxe/pull/313
> 
> On 06.04.21 11:41, Nate DeSimone wrote:
> > Hi Marvin,
> >
> > Great to meet you and welcome back! Glad you hear you are 
> > interested! Completing a formal verification of a PE/COFF
> loader is certainly impressive. Was this done with some sort of 
> automated theorem proving? It would seem a rather arduous task doing 
> an inductive proof for 

Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

[Nate DeSimone]

Hi Benjamin,

Since Google is expecting students to only work 18 hours a week on their GSoC 
projects this year that should be totally fine. It might not be a bad idea to 
mention it in your application just so we have a good paper trail.

Best Regards,
Nate

From: Benjamin Doron 
Sent: Monday, April 12, 2021 11:35 AM
To: Desimone, Nathaniel L ; devel@edk2.groups.io
Subject: Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

Hi again,
I forgot to mention previously that I will likely be taking one university 
course during the summer, likely occupying 3-5 hours per week. I don't imagine 
this would be an issue, but let me know if I should mention it in my project 
proposal (or if mentioning it here is sufficient).

> I see your application in the system and it looks great, nicely written and 
> formatted! Thank you Benjamin we will be in touch.

Great to hear, thanks!

Best regards,
Benjamin Doron


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

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

[Michael D Kinney]

Hi Marvin,

If it has not already been considered, one option is to submit a new
instance of the PE/COFF Library, so both the existing one and the new
one are available to the ecosystem.

This allows you to be successful in submitting code outlined in your 
proposal and gives the ecosystem time to evaluate and decide when/if
to switch from the old to the new.

Mike

> -Original Message-
> From: Marvin Häuser 
> Sent: Monday, April 12, 2021 10:22 AM
> To: devel@edk2.groups.io; Desimone, Nathaniel L 
> ; Laszlo Ersek ; Andrew
> Fish ; Kinney, Michael D 
> Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader
> 
> Good day Nate,
> 
> As you seem to be mostly in charge of the GSoC side of things, I direct
> this at you, but of course everyone is welcome to comment.
> 
> I think I finished my first round of investigations just in time for the
> deadline. You can find a list of BZs attached[1]. Please note that 1)
> some are declared security issues and may not be publicly accessible,
> and 2) that this list is far from complete. I only added items that are
> a) not implicitly fixed by "simply" deploying the new Image Loader
> (*some* important prerequisites are listed), and b) I am confident are
> actual issues (or things to consider) I believe to know how to approach.
> 
> I have taken notes about more things, e.g. the existence of the security
> architectural protocols, which I could not find a rationale for. I can
> prepare something for this matter, but it really needs an active
> discussion with some of the core people. I'm not sure delayed e-mail
> discussion is going to be enough, but there is an official IRC I
> suppose. :) I hope we can work something out for this.
> 
> I also hope this makes it clearer why I don't believe that we need to
> "fill" 10 weeks, but rather the opposite. This is not a matter of
> replacing a library instance, but the whole surrounding ecosystem needs
> to follow for the changes to make sense. And as I tried to make clear in
> my discussion with Michael Brown, I am not keen on preserving
> backwards-compatibility with platform code (i.e. PEI, DXE, things we
> consider "internal"), as most of it should be controlled by EDK II
> already. This of course does *not* include user code (OROMs,
> bootloaders, ...), for which I want to provide the *option* to lock some
> of them out for security, but with sane defaults that will ensure good
> compatibility.
> 
> I'd like to thank Michael Brown for his cooperation and support, because
> we recently landed changes in iPXE to allow for the strictest image
> format and permission constraints currently possible[2].
> 
> I will have to rework the submitted proposal to reflect the new
> knowledge. To be honest, seeing how the BZs kept rolling in, I am not
> convinced an amazing amount of mainlining can be accomplished during the
> 10 weeks. It may have to suffice to have a publicly accessible prototype
> (e.g. OVMF) and a subset of the planned patches on the list. I hope you
> can manage to provide some feedback before the deadline passes tomorrow.
> 
> Thank you in advance!
> 
> Best regards,
> Marvin
> 
> [1]
> https://bugzilla.tianocore.org/show_bug.cgi?id=3315
> https://bugzilla.tianocore.org/show_bug.cgi?id=3316
> https://bugzilla.tianocore.org/show_bug.cgi?id=3317
> https://bugzilla.tianocore.org/show_bug.cgi?id=3318
> https://bugzilla.tianocore.org/show_bug.cgi?id=3319
> https://bugzilla.tianocore.org/show_bug.cgi?id=3320
> https://bugzilla.tianocore.org/show_bug.cgi?id=3321
> https://bugzilla.tianocore.org/show_bug.cgi?id=3322
> https://bugzilla.tianocore.org/show_bug.cgi?id=3323
> https://bugzilla.tianocore.org/show_bug.cgi?id=3324
> https://bugzilla.tianocore.org/show_bug.cgi?id=3326
> https://bugzilla.tianocore.org/show_bug.cgi?id=3327
> https://bugzilla.tianocore.org/show_bug.cgi?id=3328
> https://bugzilla.tianocore.org/show_bug.cgi?id=3329
> https://bugzilla.tianocore.org/show_bug.cgi?id=3330
> https://bugzilla.tianocore.org/show_bug.cgi?id=3331
> 
> [2] https://github.com/ipxe/ipxe/pull/313
> 
> On 06.04.21 11:41, Nate DeSimone wrote:
> > Hi Marvin,
> >
> > Great to meet you and welcome back! Glad you hear you are interested! 
> > Completing a formal verification of a PE/COFF
> loader is certainly impressive. Was this done with some sort of automated 
> theorem proving? It would seem a rather arduous
> task doing an inductive proof for an algorithm like that by hand! I 
> completely agree with you that getting a formally
> verified PE/COFF loader into mainline is undoubtably valuable and would pay 
> security dividends for years to come.
> >
> > Admittedly, this is an area of computer science that I don't have a great 
> > deal of experience with. The furthest I have
> gone on this topic is writing out proofs for simple algorithms on exams in my 
> Algorithms class in college. Regardless you
> have a much better idea of what the current status is of the work that you 
> and Vitaly have done. I guess my only 

[edk2-devel] Event: TianoCore Community Meeting - APAC/NAMO - Thursday, 6 May 2021 #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1126245 
UID:i3bj.1618264485620515019.t...@groups.io
DTSTAMP:20210412T215445Z
ORGANIZER;CN=Puja Pandya:mailto:puja.pan...@intel.com
DTSTART:20210507T023000Z
DTEND:20210507T033000Z
SUMMARY:TianoCore Community Meeting - APAC/NAMO
DESCRIPTION:Agenda:\n\n* Events update\n* Stewards download\n* Stable tag
 \n* GSoC update\n* Opens\n\n_
 ___\n\nMicrosoft Teams meeting\n\n*Join o
 n your computer or mobile app*\n\nClick here to join the meeting ( https:
 //teams.microsoft.com/l/meetup-join/19%3ameeting_Nzk4NmUzOTItNzIzNC00MTVk
 LTgxZDUtMDAwOTIxOGI2OWJk%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88
 -e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%220d960867-aa36-403f-8446-
 f96a6cce5fa4%22%7d )\n\n*Join with a video conferencing device*\n\nteams@
 conf.intel.com\n\nVideo Conference ID: 119 712 073 2\n\nAlternate VTC dia
 ling instructions ( https://conf.intel.com/teams/?conf=1197120732=tea
 ms=conf.intel.com=test_call )\n\nLearn More ( https://aka.ms/JoinT
 eamsMeeting ) | Meeting options ( https://teams.microsoft.com/meetingOpti
 ons/?organizerId=0d960867-aa36-403f-8446-f96a6cce5fa4=46c98d88-e
 344-4ed4-8496-4ed7712e255d=19_meeting_Nzk4NmUzOTItNzIzNC00MTVkLT
 gxZDUtMDAwOTIxOGI2OWJk@thread.v2=0=en-US )\n\n
 
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_Nzk4NmUzO
 TItNzIzNC00MTVkLTgxZDUtMDAwOTIxOGI2OWJk%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%220d960867-
 aa36-403f-8446-f96a6cce5fa4%22%7d
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

[edk2-devel] Event: TianoCore Community Meeting - EMEA / NAMO - Thursday, 6 May 2021 #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1126241 
UID:xcl0.1618263939703459918.s...@groups.io
DTSTAMP:20210412T214539Z
ORGANIZER;CN=Puja Pandya:mailto:puja.pan...@intel.com
DTSTART:20210506T16Z
DTEND:20210506T17Z
SUMMARY:TianoCore Community Meeting - EMEA / NAMO
DESCRIPTION:Agenda:\n\n* Events update\n* Stewards download\n* Stable tag
 \n* GSoC update\n* Opens\n\nMicrosoft Teams meeting\n\n*Join on your comp
 uter or mobile app*\n\nClick here to join the meeting ( https://teams.mic
 rosoft.com/l/meetup-join/19%3ameeting_OTQ4NGExODMtOGRiOC00MmM0LWJhZTMtNzU
 1NDI2ZTc3MTNh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-
 8496-4ed7712e255d%22%2c%22Oid%22%3a%220d960867-aa36-403f-8446-f96a6cce5fa
 4%22%7d )\n\n*Join with a video conferencing device*\n\nteams@conf.intel.
 com\n\nVideo Conference ID: 119 993 291 6\n\nAlternate VTC dialing instru
 ctions ( https://conf.intel.com/teams/?conf=1199932916=teams=conf.i
 ntel.com=test_call )\n\nLearn More ( https://aka.ms/JoinTeamsMeeting
  ) | Meeting options ( https://teams.microsoft.com/meetingOptions/?organi
 zerId=0d960867-aa36-403f-8446-f96a6cce5fa4=46c98d88-e344-4ed4-84
 96-4ed7712e255d=19_meeting_OTQ4NGExODMtOGRiOC00MmM0LWJhZTMtNzU1N
 DI2ZTc3MTNh@thread.v2=0=en-US )
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTQ4NGExO
 DMtOGRiOC00MmM0LWJhZTMtNzU1NDI2ZTc3MTNh%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%220d960867-
 aa36-403f-8446-f96a6cce5fa4%22%7d
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Samer El-Haj-Mahmoud]

Sunny,

Thanks for sending this!

This was tested by several RPi4 users and confirmed to fix at least the 
following issue:

https://github.com/pftf/RPi4/issues/144
https://github.com/pftf/RPi4/issues/114

It *may* also fix the following issues (to be confirmed):
https://github.com/pftf/RPi4/issues/117
https://github.com/pftf/RPi4/issues/136

Please add references to these issues (at least confirmed ones) in the commit 
message when you send the v2 of the patch.

With that,

Acked-by: Samer El-Haj-Mahmoud 



> -Original Message-
> From: Sunny Wang 
> Sent: Monday, April 12, 2021 5:06 AM
> To: devel@edk2.groups.io
> Cc: Sunny Wang ; Samer El-Haj-Mahmoud
> ; Jeremy Linton
> ; Pete Batard ; Ard Biesheuvel
> ; Sunny Wang 
> Subject: [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast
> Boot
>
> This is a fix for https://github.com/pftf/RPi4/issues/114.
>
> Changes:
>   1. Add a setup option called Boot Policy and consume the setting
>  during boot to whether perform or skip ConnectAll.
>   2. The Default setting is set to Full discovery because it is not
>  worth enabling Fast boot by default on RaspberryPi systems.
>  Enabling it just saves boot time about 1 second, but caused a
>  lot of issues.
>
> Testing Done:
>   - Booted to Standalone UEFI shell on SD card and use drivers
> command to check the result with Fast Boot and Full discovery
> settings. Then, child/device handles are created as expected.
>
> Note and to-do items:
>   - The root cause looks like that boot loaders and some tools like
> grub and iPXE haven't supported selective connect/Fast boot.
> However, system firmware should still provide a setup option for
> user to enable Fast boot with old version boot loaders and tools
> , which is why we proposed this change. We will also report this
> issue to boot loader and tool vendors/open source GitHubs.
>   - We Will add more options for connecting specific type devices so
> that we can still have the shortest boot time for all use cases.
>
> Cc: Samer El-Haj-Mahmoud 
> Cc: Jeremy Linton 
> Cc: Pete Batard 
> Cc: Ard Biesheuvel 
> Signed-off-by: Sunny Wang 
> ---
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
>  .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
>  .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
>  Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
>  .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
>  .../PlatformBootManagerLib.inf   |  1 +
>  Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
>  Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
>  Platform/RaspberryPi/RaspberryPi.dec |  2 ++
>  10 files changed, 80 insertions(+), 9 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> index 22f86d4d44..d3c5869949 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> @@ -1,6 +1,6 @@
>  /** @file  *- *  Copyright (c) 2019 - 2020, ARM Limited. All rights 
> reserved.+ *
> Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.  *  Copyright (c)
> 2018 - 2020, Andrei Warkentin   *  *  SPDX-
> License-Identifier: BSD-2-Clause-Patent@@ -281,6 +281,15 @@
> SetupVariables (
>  );   } +  Size = sizeof (UINT32);+  Status = 
> gRT->GetVariable
> (L"BootPolicy",+  ,+  
> NULL, ,
> );+  if (EFI_ERROR (Status)) {+Status = PcdSet32S (PcdBootPolicy,
> PcdGet32 (PcdBootPolicy));+ASSERT_EFI_ERROR (Status);+  }+   Size =
> sizeof (UINT32);   Status = gRT->GetVariable (L"SdIsArasan",
> ,diff --git
> a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> index d51e54e010..032e40b0c3 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> @@ -2,7 +2,7 @@
>  # #  Component description file for the RasbperryPi DXE platform config
> driver. #-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.+#
> Copyright (c) 2019 - 2021, ARM Limited. All rights reserved. #  Copyright (c)
> 2018 - 2020, Andrei Warkentin  # #  SPDX-
> License-Identifier: BSD-2-Clause-Patent@@ -93,6 +93,7 @@
>gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
> gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
> gRaspberryPiTokenSpaceGuid.PcdFanTemp+
> gRaspberryPiTokenSpaceGuid.PcdBootPolicy  [Depex]   gPcdProtocolGuid
> AND gRaspberryPiFirmwareProtocolGuiddiff --git
> a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> index 466fa852cb..7b14fdf39f 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> +++ 

Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

[Brijesh Singh]

On 4/12/21 11:23 AM, Laszlo Ersek wrote:
> On 04/10/21 00:43, Brijesh Singh wrote:
>> On 4/9/21 7:24 AM, Laszlo Ersek wrote:
>>> On 04/08/21 13:59, Brijesh Singh wrote:
 On 4/8/21 4:58 AM, Laszlo Ersek wrote:
> On 03/24/21 16:31, Brijesh Singh wrote:
>> At this time we only support the pre-validation. OVMF detects all
>> the available system RAM in the PEI phase. When SEV-SNP is
>> enabled, the memory is validated before it is made available to
>> the EDK2 core.
> Can you describe this in a bit more detail, before I look at the
> individual patches? Specifically, what existing logic in the PEI
> phase was taken, and extended, and how?
 One of the key requirement is that the guest private pages much be
 validated before the access. If guest tries to access the pages
 before the validation then it will result in #VC
 (page-not-validated) exception. To avoid the #VC, we propose the
 validating the memory before the access. We will incrementally add
 the support to lazy validate (i.e validate on access).
>>> What is the primary threat (in simple terms please) that validation
>>> is supposed to prevent?
>>
>> To protect against the memory re-mapping attack the guest pages must
>> be validated. The idea is that every guest page can map only to a
>> single physical memory page at one time.
> I don't understand. How can a given guest page frame map to multiple
> host page frames?
>
> Do you mean that the situation to prevent is when multiple guest page
> frames (GPAs) map to the same host page frame, as set up by the
> hypervisor?
>
A malicious hypervisor may attempt to remap validated gpa to a different
host frame. The PVALIDATE is designed to protect against those type of
attacks. See
https://static.sched.com/hosted_files/lsseu2019/65/SEV-SNP%20Slides%20Nov%201%202019.pdf
(slide 13). You can also find more information about it in the SEV-SNP
whitepaper.


>>> And, against that particular threat, does pre-validation offer some
>>> protection, or will that only come with lazy validation?
>> For the hardware it does not matter how the memory was validated --
>> lazy vs prevalidate. Both approaches use the PVALIDATE instruction to
>> validate the page.
>>
>> In the case of pre-validation, the memory is validated before the
>> access. Whereas in the lazy validation, the access will cause a fault
>> and fault handler should validate the page and retry the access. Its
>> similar to a page fault handler, OS can populate the page table or
>> back the pages on demand.
>>
>> The only downside of pre-validation is, we will take a hit on the boot
>> time. The GHCB spec provides method by which we can batch multiple
>> requests at once to minimize the context switches.
> If pre-validation is simpler, and the only drawback is a one-time hit
> during boot, then wouldn't it be better to stick with pre-validation
> forever? I expect that would be a lot simpler for (a) the #VC handlers,
> (b) the tracking of the "already validated" information.

This could be an issue for the larger VMs. The boot delay will vary
based on the VM size. In addition to the boot delay,  the PVALIDATE
instruction requires that there is a valid entry for the page in the
nested page table. If the entry does not exist in the NPT then HV will
get #NPF and will fill the NPT with the backing host page. By using the
lazy-validation we can push allocation of the backing pages to only when
required and thus release the memory pressure on the VMM.


>
>
 Similar to SEV, the OVMF_CODE.fd is encrypted through the SNP
 firmware before the launch. The SNP firmware also validates the
 memory page after encrypting. This allows us to boot the initial
 entry code without guest going through the validation process.

 The OVMF reset vector uses few data pages (e.g page table, early Sec
 stack). Access to these data pages will result in #VC. There are two
 approaches we can take to validate these data pages:

 1. Ask SNP firmware to pre-validate it -- SNP firmware provides an
 special command that can be used to pre-validate the pages without
 affecting the measurement.
>>> This means the two pflash chips, right?
>>
>> This does not need to be two pflash chips. The SNP firmware command
>> does not know anything about the ROM or pflash chip. The command
>> accepts the system physical address that need to be validated by the
>> firmware. In patch #2, OVMF provides a range of data pages that need
>> to be validated by the SNP firmware before booting the guest.
> I guess my question related to the guest code that executes from pflash,
> and/or accesses data from pflash, before the guest itself could ask for
> any validation. Such as, the reset vector (which runs from pflash).
> Then, some non-volatile UEFI variable data that resides in the other
> pflash chip, and is accessed (read-only) during the PEI phase (the
> memory type information variable namely). I understood 

[edk2-devel] [edk2-platforms][PATCH V3 0/6] Platform/Sgi: improvements in RD platform support

[Pranav Madhu]

Changes since V2:
- Rebase the patches on top of latest master branch
- Addressed comments from Sami

Changes since V1:
- Rebase the patches on top of latest master branch
- Add three more patches to the series
- Picked up Sami's R-b tags on applicable patches

This patch series contains assorted cleanups for the RD platforms. The
first patch in this series includes the SSDT table for both the RD-V1
single chip and multi-chip platform. The second and third patches in
this series cleanup the ACPI processor ID and MPIDR values for RD-V1 in
multichip configuration. The fourth patch in this series updates the
DSDT/SSDT table revision as per ACPI specification 6.3. The fifth patch
adds PCDs for timer interrupts as interrupt mapping is different RD-N2
platform. And the last patch in this series adds SMMU and timer entries
into memory description table to support Arm SystemReady SR SBSA tests.

Link to github branch with the patches in this series -
https://github.com/Pranav-Madhu/edk2-platforms/tree/topics/rd/rd-cleanup

Pranav Madhu (6):
  Platform/Sgi: include SSDT table for RD-V1 platform
  Platform/Sgi: fix the list of CPU devices on RD-V1-MC platform
  Platform/Sgi: fix CPU acpi-id for RD-V1-MC platform
  Platform/Sgi: update ACPI table revision
  Platform/Sgi: define PCD for timer interrupt numbers
  Platform/Sgi: add SMMU and timer entries to memory description table

 Platform/ARM/SgiPkg/SgiPlatform.dec   | 18 +++
 Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc  | 10 ++
 Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc | 10 ++
 Platform/ARM/SgiPkg/SgiPlatform.dsc.inc   | 15 -
 .../SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf  |  4 +++
 .../SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf  |  4 +++
 .../AcpiTables/RdN1EdgeX2AcpiTables.inf   |  4 +++
 .../ARM/SgiPkg/AcpiTables/RdN2AcpiTables.inf  |  4 +++
 .../ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf  |  5 +++
 .../SgiPkg/AcpiTables/RdV1McAcpiTables.inf|  5 +++
 .../SgiPkg/AcpiTables/Sgi575AcpiTables.inf|  4 +++
 .../Library/PlatformLib/PlatformLib.inf   | 11 +++
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  4 ---
 .../Library/PlatformLib/PlatformLibMem.c  | 32 ---
 Platform/ARM/SgiPkg/AcpiTables/Gtdt.aslc  |  8 ++---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl   |  4 +--
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl   |  4 +--
 Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl  |  4 +--
 Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl  |  4 +--
 .../ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl | 10 ++
 .../ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc| 24 +++---
 .../ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl |  4 +--
 Platform/ARM/SgiPkg/AcpiTables/Ssdt.asl   |  4 +--
 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl|  4 +--
 24 files changed, 153 insertions(+), 47 deletions(-)

-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73977): https://edk2.groups.io/g/devel/message/73977
Mute This Topic: https://groups.io/mt/82046076/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 V3 6/6] Platform/Sgi: add SMMU and timer entries to memory description table

[Pranav Madhu]

Add PCDs for base address and address space size for generic timer and
SMMU controllers. Use those PCDs to add platform memory map entries. The
ServerReady SBSA tests, when executed, accesses these controllers and so
the memory mapping for generic timer and SMMU controllers are required.

In addition to this, PCDs for watchdog timer controller base address and
size are introduced instead of using macros for the same. This allows
the base address and address space size for watchdog timer controller to
be specified by platform description files.

Signed-off-by: Pranav Madhu 
Reviewed-by: Sami Mujawar 
---
 Platform/ARM/SgiPkg/SgiPlatform.dec  | 14 -
 Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc |  4 +++
 Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc|  4 +++
 Platform/ARM/SgiPkg/SgiPlatform.dsc.inc  | 10 ++
 Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf  | 11 +++
 Platform/ARM/SgiPkg/Include/SgiPlatform.h|  4 ---
 Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c | 32 
+---
 7 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
b/Platform/ARM/SgiPkg/SgiPlatform.dec
index 86ead241a67c..3effd49592ea 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dec
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
@@ -57,11 +57,23 @@
   gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x|UINT64|0x000E
   gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x0|UINT64|0x000F
 
-  # Timer & Watchdog interrupts
+  # Counter, Timer and Watchdog
   gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|0|UINT32|0x0011
   gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|0|UINT32|0x0012
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Base|0|UINT32|0x0015
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Size|0|UINT32|0x0016
+  gArmSgiTokenSpaceGuid.PcdTimerControlBase|0|UINT32|0x0017
+  gArmSgiTokenSpaceGuid.PcdTimerControlSize|0|UINT32|0x0018
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadBase|0|UINT32|0x0019
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadSize|0|UINT32|0x001A
+  gArmSgiTokenSpaceGuid.PcdWdogBase|0|UINT32|0x001B
+  gArmSgiTokenSpaceGuid.PcdWdogSize|0|UINT32|0x001C
   gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|0|UINT32|0x0013
   gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|0|UINT32|0x0014
 
+  # SMMU
+  gArmSgiTokenSpaceGuid.PcdSmmuBase|0|UINT32|0x001D
+  gArmSgiTokenSpaceGuid.PcdSmmuSize|0|UINT32|0x001E
+
 [Ppis]
   gNtFwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 0x9b, 
0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
index efbb013b0b60..d3d650323891 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
@@ -50,3 +50,7 @@
   gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|91
   gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|93
   gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|94
+
+  # SMMU
+  gArmSgiTokenSpaceGuid.PcdSmmuBase|0x4F00
+  gArmSgiTokenSpaceGuid.PcdSmmuSize|0x0100
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
index 1167f1a6ff9d..c593156e17be 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
@@ -50,3 +50,7 @@
   gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|108
   gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|110
   gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|111
+
+  # SMMU
+  gArmSgiTokenSpaceGuid.PcdSmmuBase|0x4000
+  gArmSgiTokenSpaceGuid.PcdSmmuSize|0x1000
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
index 12a8f8884c89..42e3600d15f4 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
@@ -152,6 +152,16 @@
   # Ethernet / Virtio Network
   gArmSgiTokenSpaceGuid.PcdVirtioNetSize|0x1
 
+  # Counter, Timer and Watchdog
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Base|0x2A83
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Size|0x0001
+  gArmSgiTokenSpaceGuid.PcdTimerControlBase|0x2A81
+  gArmSgiTokenSpaceGuid.PcdTimerControlSize|0x0001
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadBase|0x2A80
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadSize|0x0001
+  gArmSgiTokenSpaceGuid.PcdWdogBase|0x2A44
+  gArmSgiTokenSpaceGuid.PcdWdogSize|0x0002
+
   #
   # Set the base address and size of the buffer used
   # for communication between the Normal world edk2
diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf 
b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
index 333247d0d808..22e247ea4fae 100644
--- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
+++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
@@ -64,9 +64,20 @@
 
   gArmTokenSpaceGuid.PcdMmBufferBase
   gArmTokenSpaceGuid.PcdMmBufferSize
+
   gArmSgiTokenSpaceGuid.PcdSmcCs0Base
   gArmSgiTokenSpaceGuid.PcdSmcCs1Base
+  

Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

[Benjamin Doron]

Hi again,
I forgot to mention previously that I will likely be taking one university 
course during the summer, likely occupying 3-5 hours per week. I don't imagine 
this would be an issue, but let me know if I should mention it in my project 
proposal (or if mentioning it here is sufficient).

> I see your application in the system and it looks great, nicely written and 
> formatted! Thank you Benjamin we will be in touch.

Great to hear, thanks!

Best regards,
Benjamin Doron


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73984): https://edk2.groups.io/g/devel/message/73984
Mute This Topic: https://groups.io/mt/81738382/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 V3 4/6] Platform/Sgi: update ACPI table revision

[Pranav Madhu]

Fix the ACPI DSDT/SSDT table version numbers. As per ACPI 6.3
specification, the DSDT/SSDT table should use version 2 instead of 1. In
addition to this, update 'PcdAcpiExposedTableVersions' to avoid building
RSDT table into ACPI firmware volume because the platforms supported
under SgiPkg are 64-bit systems only and require only the XSDT table.

Signed-off-by: Pranav Madhu 
Reviewed-by: Sami Mujawar 
---
 Platform/ARM/SgiPkg/SgiPlatform.dsc.inc  | 5 -
 Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl   | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl   | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/Ssdt.asl  | 4 ++--
 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl   | 4 ++--
 9 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
index ed7c7d6c4581..12a8f8884c89 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
+#  Copyright (c) 2018-2021, ARM Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -106,6 +106,9 @@
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x8000
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x7F00
 
+  # ACPI Table Version
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
+
   #
   # PCIe
   #
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
index d66c7cbf4183..04fd3bd0a1f8 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
+*  Copyright (c) 2018-2021, ARM Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -10,7 +10,7 @@
 #include "SgiPlatform.h"
 #include "SgiAcpiHeader.h"
 
-DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+DefinitionBlock ("DsdtTable.aml", "DSDT", 2, "ARMLTD", "ARMSGI",
  EFI_ACPI_ARM_OEM_REVISION) {
   Scope (_SB) {
 //
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
index cb05eed35878..d9bac33898b1 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
+*  Copyright (c) 2018-2021, ARM Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -10,7 +10,7 @@
 #include "SgiPlatform.h"
 #include "SgiAcpiHeader.h"
 
-DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+DefinitionBlock ("DsdtTable.aml", "DSDT", 2, "ARMLTD", "ARMSGI",
  EFI_ACPI_ARM_OEM_REVISION) {
   Scope (_SB) {
 
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl
index 8688fd8d6b90..42cb8655b4fb 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2020, Arm Ltd. All rights reserved.
+*  Copyright (c) 2020-2021, Arm Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -10,7 +10,7 @@
 #include "SgiPlatform.h"
 #include "SgiAcpiHeader.h"
 
-DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+DefinitionBlock ("DsdtTable.aml", "DSDT", 2, "ARMLTD", "ARMSGI",
  EFI_ACPI_ARM_OEM_REVISION) {
   Scope (_SB) {
 Device (CP00) { // Neoverse N2 core 0
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl
index 7cc0614f4d60..f3e31e4085a3 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2020, Arm Ltd. All rights reserved.
+*  Copyright (c) 2020-2021, Arm Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -10,7 +10,7 @@
 #include "SgiPlatform.h"
 #include "SgiAcpiHeader.h"
 
-DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+DefinitionBlock ("DsdtTable.aml", "DSDT", 2, "ARMLTD", "ARMSGI",
  EFI_ACPI_ARM_OEM_REVISION) {
   Scope (_SB) {
 Device (CP00) { // Neoverse V1 core 0
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl 

[edk2-devel] [edk2-platforms][PATCH V3 5/6] Platform/Sgi: define PCD for timer interrupt numbers

[Pranav Madhu]

The generic timer and watchdog timer interrupt numbers on the RD-N2
platform is different than those on the other platforms supported by
SgiPkg. So in order to reuse the existing GTDT ACPI table for all the
supported platforms including RD-N2, introduce and use PCD to provide
the interrupt numbers for watchdog and generic timers.

Signed-off-by: Pranav Madhu 
Reviewed-by: Sami Mujawar 
---
 Platform/ARM/SgiPkg/SgiPlatform.dec | 6 ++
 Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc| 6 ++
 Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc   | 6 ++
 Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdN2AcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf | 4 
 Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf | 4 
 Platform/ARM/SgiPkg/AcpiTables/Gtdt.aslc| 8 
 11 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
b/Platform/ARM/SgiPkg/SgiPlatform.dec
index 3f0d38a013f2..86ead241a67c 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dec
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
@@ -57,5 +57,11 @@
   gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x|UINT64|0x000E
   gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x0|UINT64|0x000F
 
+  # Timer & Watchdog interrupts
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|0|UINT32|0x0011
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|0|UINT32|0x0012
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|0|UINT32|0x0013
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|0|UINT32|0x0014
+
 [Ppis]
   gNtFwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 0x9b, 
0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
index e423a6b50c91..efbb013b0b60 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
@@ -44,3 +44,9 @@
   gArmTokenSpaceGuid.PcdPciMmio64Base|0x50
   gArmTokenSpaceGuid.PcdPciMmio64Size|0x30
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x6000
+
+  # Timer & Watchdog interrupts
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|92
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|91
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|93
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|94
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
index 41291eddfe74..1167f1a6ff9d 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
@@ -44,3 +44,9 @@
   gArmTokenSpaceGuid.PcdPciMmio64Base|0x40
   gArmTokenSpaceGuid.PcdPciMmio64Size|0x40
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x101000
+
+  # Timer & Watchdog interrupts
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|109
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|108
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|110
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|111
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
index 7ebd70b197a6..2dd2275665a2 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
@@ -50,11 +50,15 @@
   gArmTokenSpaceGuid.PcdPciBusMin
   gArmTokenSpaceGuid.PcdPciBusMax
 
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv
   gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSize
   gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt
   gArmSgiTokenSpaceGuid.PcdVirtioNetBaseAddress
   gArmSgiTokenSpaceGuid.PcdVirtioNetSize
   gArmSgiTokenSpaceGuid.PcdVirtioNetInterrupt
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv
 
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
index 2d4354f33018..22e33239070b 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
@@ -50,11 +50,15 @@
   gArmTokenSpaceGuid.PcdPciBusMin
   gArmTokenSpaceGuid.PcdPciBusMax
 
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv
   gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSize
   gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt
   gArmSgiTokenSpaceGuid.PcdVirtioNetBaseAddress
   gArmSgiTokenSpaceGuid.PcdVirtioNetSize
   gArmSgiTokenSpaceGuid.PcdVirtioNetInterrupt
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv
 
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git 

[edk2-devel] [edk2-platforms][PATCH V3 3/6] Platform/Sgi: fix CPU acpi-id for RD-V1-MC platform

[Pranav Madhu]

Fix the incorrect ACPI _UID (Unique ID) object for CPU devices listed
for the RD-V1-MC platform.

Signed-off-by: Pranav Madhu 
Reviewed-by: Sami Mujawar 
---
 Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc | 24 ++--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc
index 0da56ed2a39b..9b3e4f2be370 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc
@@ -69,55 +69,55 @@ STATIC EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE Madt = {
 
 // Chip 1
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core0
-  0, 0, GET_MPID(0x0100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 4, GET_MPID(0x0100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core1
-  0, 1, GET_MPID(0x01000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 5, GET_MPID(0x01000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core2
-  0, 2, GET_MPID(0x01000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 6, GET_MPID(0x01000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core3
-  0, 3, GET_MPID(0x01000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 7, GET_MPID(0x01000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 
 // Chip 2
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core0
-  0, 0, GET_MPID(0x0200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 8, GET_MPID(0x0200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core1
-  0, 1, GET_MPID(0x02000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 9, GET_MPID(0x02000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core2
-  0, 2, GET_MPID(0x02000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 10, GET_MPID(0x02000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core3
-  0, 3, GET_MPID(0x02000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 11, GET_MPID(0x02000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 
 // Chip 3
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core0
-  0, 0, GET_MPID(0x0300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 12, GET_MPID(0x0300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core1
-  0, 1, GET_MPID(0x03000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 13, GET_MPID(0x03000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core2
-  0, 2, GET_MPID(0x03000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 14, GET_MPID(0x03000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core3
-  0, 3, GET_MPID(0x03000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 15, GET_MPID(0x03000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
   },
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73980): https://edk2.groups.io/g/devel/message/73980
Mute This Topic: https://groups.io/mt/82046080/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 V3 2/6] Platform/Sgi: fix the list of CPU devices on RD-V1-MC platform

[Pranav Madhu]

RD-V1-MC platform has four CPUs in each of its four coherently connected
chips. So remove a incorrect CPU device entry in DSDT table that lists a
additional non-existent CPU.

Signed-off-by: Pranav Madhu 
Reviewed-by: Sami Mujawar 
---
 Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl
index aef6473857b0..9bf57d05a646 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl
@@ -109,11 +109,5 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
"ARMSGI",
   Name (_UID, 15)
   Name (_STA, 0xF)
 }
-
-Device (CP16) { // Zeus core 16
-  Name (_HID, "ACPI0007")
-  Name (_UID, 16)
-  Name (_STA, 0xF)
-}
   } // Scope(_SB)
 }
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73979): https://edk2.groups.io/g/devel/message/73979
Mute This Topic: https://groups.io/mt/82046079/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 V3 1/6] Platform/Sgi: include SSDT table for RD-V1 platform

[Pranav Madhu]

Ssdt ACPI table in SgiPkg describes the PCIe controller and the root
complex resources. Include this table for RD-V1 and RD-V1-MC platforms.

Signed-off-by: Pranav Madhu 
Reviewed-by: Sami Mujawar 
---
 Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf   | 1 +
 Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf
index a5f936b8a758..583ffac70b71 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf
@@ -24,6 +24,7 @@
   RdV1/Dsdt.asl
   RdV1/Madt.aslc
   Spcr.aslc
+  Ssdt.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf
index 04edfc487738..d0d9473057a9 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf
@@ -26,6 +26,7 @@
   RdV1Mc/Madt.aslc
   RdV1Mc/Srat.aslc
   Spcr.aslc
+  Ssdt.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
-- 
2.17.1



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

Re: [EXTERNAL] Re: [edk2-devel] [GSoC proposal] Secure Image Loader

[Bret Barkelew via groups.io]

As always, we volunteer the UEFI Talkbox Discord for conversations of this 
nature. 

https://discord.gg/cuqjER3Juw

- Bret

From: Marvin Häuser via groups.io
Sent: Monday, April 12, 2021 10:24 AM
To: devel@edk2.groups.io; Desimone, Nathaniel 
L; Laszlo 
Ersek; Andrew Fish; Kinney, 
Michael D
Subject: [EXTERNAL] Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day Nate,

As you seem to be mostly in charge of the GSoC side of things, I direct
this at you, but of course everyone is welcome to comment.

I think I finished my first round of investigations just in time for the
deadline. You can find a list of BZs attached[1]. Please note that 1)
some are declared security issues and may not be publicly accessible,
and 2) that this list is far from complete. I only added items that are
a) not implicitly fixed by "simply" deploying the new Image Loader
(*some* important prerequisites are listed), and b) I am confident are
actual issues (or things to consider) I believe to know how to approach.

I have taken notes about more things, e.g. the existence of the security
architectural protocols, which I could not find a rationale for. I can
prepare something for this matter, but it really needs an active
discussion with some of the core people. I'm not sure delayed e-mail
discussion is going to be enough, but there is an official IRC I
suppose. :) I hope we can work something out for this.

I also hope this makes it clearer why I don't believe that we need to
"fill" 10 weeks, but rather the opposite. This is not a matter of
replacing a library instance, but the whole surrounding ecosystem needs
to follow for the changes to make sense. And as I tried to make clear in
my discussion with Michael Brown, I am not keen on preserving
backwards-compatibility with platform code (i.e. PEI, DXE, things we
consider "internal"), as most of it should be controlled by EDK II
already. This of course does *not* include user code (OROMs,
bootloaders, ...), for which I want to provide the *option* to lock some
of them out for security, but with sane defaults that will ensure good
compatibility.

I'd like to thank Michael Brown for his cooperation and support, because
we recently landed changes in iPXE to allow for the strictest image
format and permission constraints currently possible[2].

I will have to rework the submitted proposal to reflect the new
knowledge. To be honest, seeing how the BZs kept rolling in, I am not
convinced an amazing amount of mainlining can be accomplished during the
10 weeks. It may have to suffice to have a publicly accessible prototype
(e.g. OVMF) and a subset of the planned patches on the list. I hope you
can manage to provide some feedback before the deadline passes tomorrow.

Thank you in advance!

Best regards,
Marvin

[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3315data=04%7C01%7Cbret.barkelew%40microsoft.com%7C045c38141f1e443d1e4b08d8fdd78e23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637538450446516854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xkAIi7yRQfRtw3pKELUzpb1oo9EN4kyroCdadjEzPLQ%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3316data=04%7C01%7Cbret.barkelew%40microsoft.com%7C045c38141f1e443d1e4b08d8fdd78e23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637538450446516854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cFAacXfo69cDMpxSggXjnVpoRqYdIj21QYg%2Ffo5jp9Y%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3317data=04%7C01%7Cbret.barkelew%40microsoft.com%7C045c38141f1e443d1e4b08d8fdd78e23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637538450446516854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ssf4h8yn3zee1IaK5%2BwI5WwvOvUW4gAtjikil0pS3Fw%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3318data=04%7C01%7Cbret.barkelew%40microsoft.com%7C045c38141f1e443d1e4b08d8fdd78e23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637538450446516854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2KKVA6qqHIP2skLSLXo56av1%2FS9pL1MMJbt%2FPI9BBPM%3Dreserved=0

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg/Tcg2Smm: Initialize local Status variable

[Michael Kubacki]

Hi Laszlo and SecurityPkg maintainers,

This is a relatively straightforward patch. Please let me know if 
anything else is needed for you to submit it.


Thanks,
Michael

On 4/7/2021 9:06 AM, Laszlo Ersek wrote:

On 04/06/21 20:12, mikub...@linux.microsoft.com wrote:

From: Michael Kubacki 

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

Initializes the Status variable in TcgMmReadyToLock().

Fixes a Clang build failure:
Tcg2Smm.c - SecurityPkg\Tcg\Tcg2Smm\Tcg2Smm.c:254:7: error:
variable 'Status' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]

Initializing this variable is required to address a practical
scenario in which the return value of TcgMmReadyToLock() is
undefined based on conditional evaluation in the function.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 
Cc: Kun Qin 
Signed-off-by: Michael Kubacki 
Reviewed-by: Jiewen Yao 
---

Notes:
 V2 change:
 
 Clarify in commit message that the issue reported by Clang is not

 solely a false positive.

  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
index 589c08794bcf..f49eccb0bdf4 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
@@ -253,6 +253,8 @@ TcgMmReadyToLock (
  {
EFI_STATUS Status;
  
+  Status = EFI_SUCCESS;

+
if (mReadyToLockHandle != NULL) {
  Status = gMmst->MmiHandlerUnRegister (mReadyToLockHandle);
  mReadyToLockHandle = NULL;



Awesome, thanks!

I've also managed to look at the code now.

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo








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

Re: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

[Pandya, Shivanshi]

Hey All,

Thank you for your thoughts and responses. I have figured it out.
The branch has been updated with fix which I missed! Got the successful build 
done.

Thank you,
Shivanshi

From: Bret Barkelew 
Sent: Monday, April 12, 2021 11:32 AM
To: Andrew Fish; edk2-devel-groups-io
Cc: Pandya, Shivanshi
Subject: RE: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg


[EXTERNAL EMAIL]
To my knowledge, we do not currently have a required version; the current state 
is it either works or it doesn't, and if it doesn't it's on you to figure that 
out from the failures.

I'm not opposed to adding one - if there's interest. I'd have to think about 
the best place to add it. The idea of making it its own test is interesting. It 
wouldn't prevent you from getting other test data, but it would let you know 
you aren't on the ideal version and there may be unpredictable results. Ponder 
ponder...

- Bret

From: Andrew Fish
Sent: Monday, April 12, 2021 9:27 AM
To: edk2-devel-groups-io; Bret 
Barkelew
Cc: shivanshi.pan...@dell.com
Subject: Re: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg



On Apr 9, 2021, at 6:33 PM, Bret Barkelew via groups.io 
[nam06.safelinks.protection.outlook.com]
 
mailto:bret.barkelew=microsoft@groups.io>>
 wrote:

Andrew,
Not a scheme that I would consider a "good" scheme. You can see what we're 
running CI against (in Mu and EDK, both), by checking for the  
"UsePythonVersion" command in the .azurepipelines/pr-gate-steps.yml file.


Bret,

If I understand correctly the CI list is the recommended versions, but not the 
required versions. Do we have any concept of the required versions? I guess we 
could put a python assert to enforce min Python version? I guess we could be 
more aggressive on the required Python version (forces people to install a 
custom Python version for the edk2 build), or build a CI test that tests the 
min Python version for the tools...

Sorry mostly thinking out loud

Thanks,

Andrew Fish


Shivanshi,
I just ran a build on my system with that exact version of Python (3.9.0). Did 
your build produce a "BUILD_TOOLS_REPORT.json" file? If so, can you send it?
Can you also send the exact command that you're running when you see this issue?

Thanks!

- Bret

From: Andrew Fish
Sent: Friday, April 9, 2021 4:54 PM
To: edk2-devel-groups-io; Bret 
Barkelew
Cc: shivanshi.pan...@dell.com
Subject: [EXTERNAL] Re: [edk2-devel] Build Failed for QEMU35Pkg




On Apr 9, 2021, at 1:55 PM, Bret Barkelew via groups.io 
[nam06.safelinks.protection.outlook.com]
 
mailto:bret.barkelew=microsoft@groups.io>>
 wrote:

It looks like a Python 3.8.x vs 3.9.x issue.


Do we have a scheme to require a min Python version?

Thanks,

Andrew Fish


It looks as if you're using Mu Q35 as your platform. Can you tell me what 
branch you're on?

- Bret

From: Pandya, Shivanshi via 
groups.io
Sent: Friday, April 9, 2021 1:52 PM
To: devel@edk2.groups.io
Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

Hello,

Build failed with following call trace

build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
 [X64, VS2017, DEBUG]]
INFO -
INFO - (Please send email to devel@edk2.groups.io 
for help, attaching following call stack trace!)
INFO -
INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2635, in Main
INFO - MyBuild.Launch()
INFO -   File 

Re: [edk2-devel] [PATCH v1 1/1] UefiCpuPkg: PiSmmCpuDxeSmm: Check buffer size before accessing

[Kun Qin]

Hi Laszlo,

Thanks for the help.

Regards,
Kun

On 04/12/2021 10:36, Laszlo Ersek wrote:

On 04/07/21 18:08, Laszlo Ersek wrote:

On 04/06/21 21:52, Kun Qin wrote:

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

Current SMM Save State routine does not check the number of bytes to be
read, when it comse to read IO_INFO, before casting the incoming buffer
to EFI_SMM_SAVE_STATE_IO_INFO. This could potentially cause memory
corruption due to extra bytes are written out of buffer boundary.

This change adds a width check before copying IoInfo into output buffer.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Ray Ni 
Reviewed-by: Laszlo Ersek 
---

Notes:
 v2:
 - Update return code description [Laszlo]

  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c | 9 -
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 2 +-
  2 files changed, 9 insertions(+), 2 deletions(-)


Thanks, looks OK. I'll let Ray or Eric merge the patch.


:/

Merged as commit a7d8e28b29f2, via
.

Laszlo




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73973): https://edk2.groups.io/g/devel/message/73973
Mute This Topic: https://groups.io/mt/81899611/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/1] UefiCpuPkg: PiSmmCpuDxeSmm: Check buffer size before accessing

[Laszlo Ersek]

On 04/07/21 18:08, Laszlo Ersek wrote:
> On 04/06/21 21:52, Kun Qin wrote:
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3283
>>
>> Current SMM Save State routine does not check the number of bytes to be
>> read, when it comse to read IO_INFO, before casting the incoming buffer
>> to EFI_SMM_SAVE_STATE_IO_INFO. This could potentially cause memory
>> corruption due to extra bytes are written out of buffer boundary.
>>
>> This change adds a width check before copying IoInfo into output buffer.
>>
>> Cc: Eric Dong 
>> Cc: Ray Ni 
>> Cc: Laszlo Ersek 
>> Cc: Rahul Kumar 
>>
>> Signed-off-by: Kun Qin 
>> Reviewed-by: Ray Ni 
>> Reviewed-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> v2:
>> - Update return code description [Laszlo]
>>
>>  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c | 9 -
>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 2 +-
>>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> Thanks, looks OK. I'll let Ray or Eric merge the patch.

:/

Merged as commit a7d8e28b29f2, via
.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73972): https://edk2.groups.io/g/devel/message/73972
Mute This Topic: https://groups.io/mt/81899611/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/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Ard Biesheuvel]

On Mon, 12 Apr 2021 at 15:03, Pete Batard  wrote:
>
> Hi Sunny,
>
> Functionaly, I see no issues with this patch, and it's indeed a good
> solution to the problem of trying to satisfy everyone while fixing the
> issues we are seeing.
>
> There are however a few minor typos and whitespace issues, that I'm
> detailing below. So could you please send a v2 to address these?
>

Agree with Pete. Thanks for providing a fix for this, and please
incorporate the changes suggested by Pete.

Then, could we *please* figure out a way to get this patch on the
mailing list without Windows whitespace damage? Not sure if anything
changed recently, but not a single EDK2 patch has arrived in my
mailbox recently in a form that I could apply with 'git am'.

Thanks,
Ard.


> On 2021.04.12 10:05, Sunny Wang wrote:
> > This is a fix for https://github.com/pftf/RPi4/issues/114.
> >
> > Changes:
> >1. Add a setup option called Boot Policy and consume the setting
> >   during boot to whether perform or skip ConnectAll.
> >2. The Default setting is set to Full discovery because it is not
> >   worth enabling Fast boot by default on RaspberryPi systems.
> >   Enabling it just saves boot time about 1 second, but caused a
> >   lot of issues.
> >
> > Testing Done:
> >- Booted to Standalone UEFI shell on SD card and use drivers
> >  command to check the result with Fast Boot and Full discovery
> >  settings. Then, child/device handles are created as expected.
> >
> > Note and to-do items:
> >- The root cause looks like that boot loaders and some tools like
> >  grub and iPXE haven't supported selective connect/Fast boot.
> >  However, system firmware should still provide a setup option for
> >  user to enable Fast boot with old version boot loaders and tools
> >  , which is why we proposed this change. We will also report this
> >  issue to boot loader and tool vendors/open source GitHubs.
> >- We Will add more options for connecting specific type devices so
> >  that we can still have the shortest boot time for all use cases.
> >
> > Cc: Samer El-Haj-Mahmoud 
> > Cc: Jeremy Linton 
> > Cc: Pete Batard 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: Sunny Wang 
> > ---
> >   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
> >   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
> >   .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
> >   .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
> >   Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
> >   .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
> >   .../PlatformBootManagerLib.inf   |  1 +
> >   Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
> >   Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
> >   Platform/RaspberryPi/RaspberryPi.dec |  2 ++
> >   10 files changed, 80 insertions(+), 9 deletions(-)
> >
> > diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
> > b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> > index 22f86d4d44..d3c5869949 100644
> > --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> > +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> > @@ -1,6 +1,6 @@
> >   /** @file
> >
> >*
> >
> > - *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
> >
> > + *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
> >
> >*  Copyright (c) 2018 - 2020, Andrei Warkentin 
> > 
> >
> >*
> >
> >*  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> > @@ -281,6 +281,15 @@ SetupVariables (
> >   );
> >
> > }
> >
> >
> >
> > +  Size = sizeof (UINT32);
> >
> > +  Status = gRT->GetVariable (L"BootPolicy",
> >
> > +  ,
> >
> > +  NULL, , );
> >
> > +  if (EFI_ERROR (Status)) {
> >
> > +Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));
> >
> > +ASSERT_EFI_ERROR (Status);
> >
> > +  }
> >
> > +
> >
> > Size = sizeof (UINT32);
> >
> > Status = gRT->GetVariable (L"SdIsArasan",
> >
> > ,
> >
> > diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
> > b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> > index d51e54e010..032e40b0c3 100644
> > --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> > +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> > @@ -2,7 +2,7 @@
> >   #
> >
> >   #  Component description file for the RasbperryPi DXE platform config 
> > driver.
> >
> >   #
> >
> > -#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
> >
> > +#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
> >
> >   #  Copyright (c) 2018 - 2020, Andrei Warkentin 
> > 
> >
> >   #
> >
> >   #  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> > @@ -93,6 +93,7 @@
> > gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
> >
> > 

Re: [edk2-devel] [GSoC proposal] Secure Image Loader

[Marvin Häuser]

Good day Nate,

As you seem to be mostly in charge of the GSoC side of things, I direct 
this at you, but of course everyone is welcome to comment.


I think I finished my first round of investigations just in time for the 
deadline. You can find a list of BZs attached[1]. Please note that 1) 
some are declared security issues and may not be publicly accessible, 
and 2) that this list is far from complete. I only added items that are 
a) not implicitly fixed by "simply" deploying the new Image Loader 
(*some* important prerequisites are listed), and b) I am confident are 
actual issues (or things to consider) I believe to know how to approach.


I have taken notes about more things, e.g. the existence of the security 
architectural protocols, which I could not find a rationale for. I can 
prepare something for this matter, but it really needs an active 
discussion with some of the core people. I'm not sure delayed e-mail 
discussion is going to be enough, but there is an official IRC I 
suppose. :) I hope we can work something out for this.


I also hope this makes it clearer why I don't believe that we need to 
"fill" 10 weeks, but rather the opposite. This is not a matter of 
replacing a library instance, but the whole surrounding ecosystem needs 
to follow for the changes to make sense. And as I tried to make clear in 
my discussion with Michael Brown, I am not keen on preserving 
backwards-compatibility with platform code (i.e. PEI, DXE, things we 
consider "internal"), as most of it should be controlled by EDK II 
already. This of course does *not* include user code (OROMs, 
bootloaders, ...), for which I want to provide the *option* to lock some 
of them out for security, but with sane defaults that will ensure good 
compatibility.


I'd like to thank Michael Brown for his cooperation and support, because 
we recently landed changes in iPXE to allow for the strictest image 
format and permission constraints currently possible[2].


I will have to rework the submitted proposal to reflect the new 
knowledge. To be honest, seeing how the BZs kept rolling in, I am not 
convinced an amazing amount of mainlining can be accomplished during the 
10 weeks. It may have to suffice to have a publicly accessible prototype 
(e.g. OVMF) and a subset of the planned patches on the list. I hope you 
can manage to provide some feedback before the deadline passes tomorrow.


Thank you in advance!

Best regards,
Marvin

[1]
https://bugzilla.tianocore.org/show_bug.cgi?id=3315
https://bugzilla.tianocore.org/show_bug.cgi?id=3316
https://bugzilla.tianocore.org/show_bug.cgi?id=3317
https://bugzilla.tianocore.org/show_bug.cgi?id=3318
https://bugzilla.tianocore.org/show_bug.cgi?id=3319
https://bugzilla.tianocore.org/show_bug.cgi?id=3320
https://bugzilla.tianocore.org/show_bug.cgi?id=3321
https://bugzilla.tianocore.org/show_bug.cgi?id=3322
https://bugzilla.tianocore.org/show_bug.cgi?id=3323
https://bugzilla.tianocore.org/show_bug.cgi?id=3324
https://bugzilla.tianocore.org/show_bug.cgi?id=3326
https://bugzilla.tianocore.org/show_bug.cgi?id=3327
https://bugzilla.tianocore.org/show_bug.cgi?id=3328
https://bugzilla.tianocore.org/show_bug.cgi?id=3329
https://bugzilla.tianocore.org/show_bug.cgi?id=3330
https://bugzilla.tianocore.org/show_bug.cgi?id=3331

[2] https://github.com/ipxe/ipxe/pull/313

On 06.04.21 11:41, Nate DeSimone wrote:

Hi Marvin,

Great to meet you and welcome back! Glad you hear you are interested! 
Completing a formal verification of a PE/COFF loader is certainly impressive. 
Was this done with some sort of automated theorem proving? It would seem a 
rather arduous task doing an inductive proof for an algorithm like that by 
hand! I completely agree with you that getting a formally verified PE/COFF 
loader into mainline is undoubtably valuable and would pay security dividends 
for years to come.

Admittedly, this is an area of computer science that I don't have a great deal 
of experience with. The furthest I have gone on this topic is writing out 
proofs for simple algorithms on exams in my Algorithms class in college. 
Regardless you have a much better idea of what the current status is of the 
work that you and Vitaly have done. I guess my only question is do you think 
there is sufficient work remaining to fill the 10 week GSoC development window? 
Certainly we can use some of that time to perform the code reviews you mention 
and write up formal ECRs for the UEFI spec changes that you believe are needed.

Thank you for sending the application and alerting us to the great work you and 
Vitaly have done! I'll read your paper more closely and come back with any 
questions I still have.

With Best Regards,
Nate


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Marvin
Häuser
Sent: Sunday, April 4, 2021 4:02 PM
To: devel@edk2.groups.io; Laszlo Ersek ; Andrew Fish
; Kinney, Michael D 
Subject: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day everyone,

I'll keep the introduction brief 

Re: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

[Bret Barkelew via groups.io]

To my knowledge, we do not currently have a required version; the current state 
is it either works or it doesn’t, and if it doesn’t it’s on you to figure that 
out from the failures.

I’m not opposed to adding one – if there’s interest. I’d have to think about 
the best place to add it. The idea of making it its own test is interesting. It 
wouldn’t prevent you from getting other test data, but it would let you know 
you aren’t on the ideal version and there may be unpredictable results. Ponder 
ponder…

- Bret

From: Andrew Fish
Sent: Monday, April 12, 2021 9:27 AM
To: edk2-devel-groups-io; Bret 
Barkelew
Cc: shivanshi.pan...@dell.com
Subject: Re: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg




On Apr 9, 2021, at 6:33 PM, Bret Barkelew via 
groups.io
 
mailto:bret.barkelew=microsoft@groups.io>>
 wrote:

Andrew,
Not a scheme that I would consider a “good” scheme. You can see what we’re 
running CI against (in Mu and EDK, both), by checking for the  
“UsePythonVersion” command in the .azurepipelines/pr-gate-steps.yml file.


Bret,

If I understand correctly the CI list is the recommended versions, but not the 
required versions. Do we have any concept of the required versions? I guess we 
could put a python assert to enforce min Python version? I guess we could be 
more aggressive on the required Python version (forces people to install a 
custom Python version for the edk2 build), or build a CI test that tests the 
min Python version for the tools...

Sorry mostly thinking out loud….

Thanks,

Andrew Fish



Shivanshi,
I just ran a build on my system with that exact version of Python (3.9.0). Did 
your build produce a “BUILD_TOOLS_REPORT.json” file? If so, can you send it?
Can you also send the exact command that you’re running when you see this issue?

Thanks!

- Bret

From: Andrew Fish
Sent: Friday, April 9, 2021 4:54 PM
To: edk2-devel-groups-io; Bret 
Barkelew
Cc: shivanshi.pan...@dell.com
Subject: [EXTERNAL] Re: [edk2-devel] Build Failed for QEMU35Pkg





On Apr 9, 2021, at 1:55 PM, Bret Barkelew via 
groups.io
 
mailto:bret.barkelew=microsoft@groups.io>>
 wrote:

It looks like a Python 3.8.x vs 3.9.x issue.


Do we have a scheme to require a min Python version?

Thanks,

Andrew Fish



It looks as if you’re using Mu Q35 as your platform. Can you tell me what 
branch you’re on?

- Bret

From: Pandya, Shivanshi via 
groups.io
Sent: Friday, April 9, 2021 1:52 PM
To: devel@edk2.groups.io
Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

Hello,

Build failed with following call trace

build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
 [X64, VS2017, DEBUG]]
INFO -
INFO - (Please send email to devel@edk2.groups.io 
for help, attaching following call stack trace!)
INFO -
INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2635, in Main
INFO - MyBuild.Launch()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2430, in Launch
INFO - self._MultiThreadBuildPlatform()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2238, in _MultiThreadBuildPlatform
INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2112, in PerformAutoGen
INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2009, in _GenFfsCmd
INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, self, 
ArchList, GlobalData)
INFO -   File 

Re: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

[Andrew Fish via groups.io]

> On Apr 9, 2021, at 6:33 PM, Bret Barkelew via groups.io 
>  wrote:
> 
> Andrew,
> Not a scheme that I would consider a “good” scheme. You can see what we’re 
> running CI against (in Mu and EDK, both), by checking for the  
> “UsePythonVersion” command in the .azurepipelines/pr-gate-steps.yml file.
>

Bret,

If I understand correctly the CI list is the recommended versions, but not the 
required versions. Do we have any concept of the required versions? I guess we 
could put a python assert to enforce min Python version? I guess we could be 
more aggressive on the required Python version (forces people to install a 
custom Python version for the edk2 build), or build a CI test that tests the 
min Python version for the tools...

Sorry mostly thinking out loud…. 

Thanks,

Andrew Fish


> Shivanshi,
> I just ran a build on my system with that exact version of Python (3.9.0). 
> Did your build produce a “BUILD_TOOLS_REPORT.json” file? If so, can you send 
> it?
> Can you also send the exact command that you’re running when you see this 
> issue?
>
> Thanks!
>
> - Bret 
>
> From: Andrew Fish 
> Sent: Friday, April 9, 2021 4:54 PM
> To: edk2-devel-groups-io ; Bret Barkelew 
> 
> Cc: shivanshi.pan...@dell.com 
> Subject: [EXTERNAL] Re: [edk2-devel] Build Failed for QEMU35Pkg
>
>
> 
> 
> On Apr 9, 2021, at 1:55 PM, Bret Barkelew via groups.io 
> 
>   > wrote:
>
> It looks like a Python 3.8.x vs 3.9.x issue.
>
>
> Do we have a scheme to require a min Python version?
>
> Thanks,
>
> Andrew Fish
> 
> 
> It looks as if you’re using Mu Q35 as your platform. Can you tell me what 
> branch you’re on?
>
> - Bret 
>
> From: Pandya, Shivanshi via groups.io 
> 
> Sent: Friday, April 9, 2021 1:52 PM
> To: devel@edk2.groups.io 
> Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg
>
> Hello,
>
> Build failed with following call trace
>
> build.py...
> INFO -  : error C0DE: Unknown fatal error when processing 
> [c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
>  [X64, VS2017, DEBUG]]
> INFO -
> INFO - (Please send email to devel@edk2.groups.io 
>  for help, attaching following call stack trace!)
> INFO -
> INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2635, in Main
> INFO - MyBuild.Launch()
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2430, in Launch
> INFO - self._MultiThreadBuildPlatform()
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2238, in _MultiThreadBuildPlatform
> INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2112, in PerformAutoGen
> INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2009, in _GenFfsCmd
> INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, 
> self, ArchList, GlobalData)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
>  line 541, in GenFfsMakefile
> INFO - FdObj.GenFd(Flag=True)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
>  line 131, in GenFd
> INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
> self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
> self.DefineVarDict, Flag=Flag)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
>  line 134, in AddToBuffer
> INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
> ErasePolarity, Flag=Flag)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
>  line 127, in AddToBuffer
> INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
> IsMakefile=Flag, FvName=self.UiFvName)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
>  line 518, in GenFfs
> INFO - 

Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

[Laszlo Ersek]

On 04/10/21 00:43, Brijesh Singh wrote:
>
> On 4/9/21 7:24 AM, Laszlo Ersek wrote:
>> On 04/08/21 13:59, Brijesh Singh wrote:
>>> On 4/8/21 4:58 AM, Laszlo Ersek wrote:
 On 03/24/21 16:31, Brijesh Singh wrote:
> At this time we only support the pre-validation. OVMF detects all
> the available system RAM in the PEI phase. When SEV-SNP is
> enabled, the memory is validated before it is made available to
> the EDK2 core.
 Can you describe this in a bit more detail, before I look at the
 individual patches? Specifically, what existing logic in the PEI
 phase was taken, and extended, and how?
>>> One of the key requirement is that the guest private pages much be
>>> validated before the access. If guest tries to access the pages
>>> before the validation then it will result in #VC
>>> (page-not-validated) exception. To avoid the #VC, we propose the
>>> validating the memory before the access. We will incrementally add
>>> the support to lazy validate (i.e validate on access).
>> What is the primary threat (in simple terms please) that validation
>> is supposed to prevent?
>
>
> To protect against the memory re-mapping attack the guest pages must
> be validated. The idea is that every guest page can map only to a
> single physical memory page at one time.

I don't understand. How can a given guest page frame map to multiple
host page frames?

Do you mean that the situation to prevent is when multiple guest page
frames (GPAs) map to the same host page frame, as set up by the
hypervisor?


>> And, against that particular threat, does pre-validation offer some
>> protection, or will that only come with lazy validation?
>
> For the hardware it does not matter how the memory was validated --
> lazy vs prevalidate. Both approaches use the PVALIDATE instruction to
> validate the page.
>
> In the case of pre-validation, the memory is validated before the
> access. Whereas in the lazy validation, the access will cause a fault
> and fault handler should validate the page and retry the access. Its
> similar to a page fault handler, OS can populate the page table or
> back the pages on demand.
>
> The only downside of pre-validation is, we will take a hit on the boot
> time. The GHCB spec provides method by which we can batch multiple
> requests at once to minimize the context switches.

If pre-validation is simpler, and the only drawback is a one-time hit
during boot, then wouldn't it be better to stick with pre-validation
forever? I expect that would be a lot simpler for (a) the #VC handlers,
(b) the tracking of the "already validated" information.


>>> Similar to SEV, the OVMF_CODE.fd is encrypted through the SNP
>>> firmware before the launch. The SNP firmware also validates the
>>> memory page after encrypting. This allows us to boot the initial
>>> entry code without guest going through the validation process.
>>>
>>> The OVMF reset vector uses few data pages (e.g page table, early Sec
>>> stack). Access to these data pages will result in #VC. There are two
>>> approaches we can take to validate these data pages:
>>>
>>> 1. Ask SNP firmware to pre-validate it -- SNP firmware provides an
>>> special command that can be used to pre-validate the pages without
>>> affecting the measurement.
>> This means the two pflash chips, right?
>
>
> This does not need to be two pflash chips. The SNP firmware command
> does not know anything about the ROM or pflash chip. The command
> accepts the system physical address that need to be validated by the
> firmware. In patch #2, OVMF provides a range of data pages that need
> to be validated by the SNP firmware before booting the guest.

I guess my question related to the guest code that executes from pflash,
and/or accesses data from pflash, before the guest itself could ask for
any validation. Such as, the reset vector (which runs from pflash).
Then, some non-volatile UEFI variable data that resides in the other
pflash chip, and is accessed (read-only) during the PEI phase (the
memory type information variable namely). I understood your comments as
QEMU pre-validating those areas before guest launch. Is that correct?

Anyway, I guess at this point I should just start reviewing the series.

Some more comments below.


>> - We need more areas made accessible in SEC than just the
>> decompression buffer; for example the temporary SEC/PEI heap and
>> stack, and (IIRC) various special SEV-ES areas laid out via MEMFD.
>> Where are all of those handled / enumerated?
>
>
> Sorry, I simplified my response by saying just decompression. You are
> right that its more than the decompression buffer. In my current
> patch, the SEC phase validates all the memory up to
> PcdOvmfDecompressionScratchEnd (which includes more than just output
> buffer). See patch #13.

That sounds good (will check the patch out of course).


>>> One of the important thing is we should *never* validate the pages
>>> twice.
>> What are the symptoms / consequences of:
>>
>> - the guest 

Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in VarCheckPolicyLib

[Bret Barkelew via groups.io]

Looks like we have the requisite approvals. Shall I create a PR?

- Bret

From: Wu, Hao A via groups.io
Sent: Sunday, April 11, 2021 7:23 PM
To: Bret Barkelew; 
devel@edk2.groups.io
Cc: Wang, Jian J
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize 
temp variable in VarCheckPolicyLib

> -Original Message-
> From: Bret Barkelew 
> Sent: Saturday, April 10, 2021 2:25 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A 
> Subject: [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in
> VarCheckPolicyLib
>
> DumpVariablePolicy() will return EFI_INVALID_PARAMETER if the Buffer
> pointer is NULL and the indirect Size is anything but 0. Since this TempSize
> was not being initialized it is very likely that this sequence would not 
> return
> the total buffer size as expected.
>
> Bugzilla: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3310data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cdd597013a0874fa676f708d8fd5a02e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637537910324146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qxCQ6vccJFzG8gH9qDBHD9xnl%2FCs3DdVUuMtHspanfY%3Dreserved=0
>
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Signed-off-by: Bret Barkelew 
> ---
>  MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> index 14e1904e96d3..e50edb4ffc5a 100644
> --- a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> +++ b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> @@ -216,6 +216,7 @@ VarCheckPolicyLibMmiHandler (
>  DumpParamsOut->TotalSize = 0;
>  DumpParamsOut->PageSize = 0;
>  DumpParamsOut->HasMore = FALSE;
> +TempSize = 0;
>  SubCommandStatus = DumpVariablePolicy (NULL, );


Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


>  if (SubCommandStatus == EFI_BUFFER_TOO_SMALL && TempSize > 0) {
>mCurrentPaginationCommand =
> VAR_CHECK_POLICY_COMMAND_DUMP;
> --
> 2.28.0.windows.1








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

Re: [edk2-devel] [PATCH] IntelSiliconPkg/ShadowMicrocode: Fix build failure

[Chaganty, Rangasai V]

Reviewed-by: Sai Chaganty  

-Original Message-
From: Ni, Ray  
Sent: Monday, April 12, 2021 1:45 AM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V 
Subject: [PATCH] IntelSiliconPkg/ShadowMicrocode: Fix build failure

The commit 7e4c6f982a0accd5aa86337b46d20199db989aeb
updated ShadowMicrocode module to consume MicrocodeLib.

But the change caused the build failure.

The patch fixed the build failure and also verified the change in real platform.

Signed-off-by: Ray Ni 
Cc: Rangasai V Chaganty 
---
 .../Feature/ShadowMicrocode/ShadowMicrocodePei.c   | 3 +--
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c
index 4e4b69a0ca..7f4a3f8fbd 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicroc
+++ odePei.c
@@ -291,7 +291,6 @@ ShadowMicrocode (
   UINTN MaxPatchNumber;   CPU_MICROCODE_HEADER 
 *MicrocodeEntryPoint;   UINTN PatchCount;- 
 UINTN DataSize;   UINTN
 TotalSize;   UINTN TotalLoadSize; @@ -342,7 +341,7 
@@ ShadowMicrocode (
 if (FitEntry[Index].Type == FIT_TYPE_01_MICROCODE) {   
MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (UINTN) FitEntry[Index].Address; 
  TotalSize = GetMicrocodeLength (MicrocodeEntryPoint);-  if 
(IsValidMicrocode (MicrocodeEntryPoint, TotalSize, MicrocodeCpuId, CpuIdCount, 
FALSE)) {+  if (IsValidMicrocode (MicrocodeEntryPoint, TotalSize, 0, 
MicrocodeCpuId, CpuIdCount, FALSE)) { 
PatchInfoBuffer[PatchCount].Address = (UINTN) MicrocodeEntryPoint; 
PatchInfoBuffer[PatchCount].Size= TotalSize; TotalLoadSize += 
TotalSize;diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
index edc79c9b9c..5e0de7e19a 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
@@ -39,6 +39,7 @@
   
MicrocodeFlashAccessLib|IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.inf
   
PeiGetVtdPmrAlignmentLib|IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf+
  MicrocodeLib|UefiCpuPkg/Library/MicrocodeLib/MicrocodeLib.inf  
[LibraryClasses.common.PEIM]   
PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf-- 
2.27.0.windows.1



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

[edk2-devel] GCC49 DEBUG AARCH64 and ARM builds use -O0

[Rebecca Cran]

I noticed the GCC49 (and GCC48) AARCH64 and ARM DEBUG builds use -O0, 
unlike IA32 and X64 platforms which build with -Os.


e.g. from 
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template 
:


DEBUG_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -O0

Is that deliberate, or should it be like X64 where DEBUG builds are 
optimized and NOOPT is used when unoptimized binaries are needed?


--
Rebecca Cran


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

[edk2-devel] [PATCH v1 1/1] Fix AsmReadMsr64() and AsmWriteMsr64() with GCC toolchain

[Takuto Naito]

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

1. AsmReadMsr64() in X64/GccInlinePriv.c
AsmReadMsr64 can return uninitialized value if FilterBeforeMsrRead
returns False. This causes build error with the CLANG toolchain.

2. AsmWriteMsr64() in X64/GccInlinePriv.c
In the case that FilterBeforeMsrWrite changes Value and returns True,
The original Value, not the changed Value, is written to the MSR.
This behavior is different from the one of AsmWriteMsr64() in
X64/WriteMsr64.c for the MSFT toolchain.

Signed-off-by: Takuto Naito 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
---
 MdePkg/Library/BaseLib/X64/GccInlinePriv.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c 
b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
index e4920f2116..244bd62ee6 100644
--- a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
+++ b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
@@ -80,7 +80,7 @@ AsmReadMsr64 (
   }
   FilterAfterMsrRead (Index, );
 
-  return (((UINT64)HighData) << 32) | LowData;
+  return Value;
 }
 
 /**
@@ -111,11 +111,10 @@ AsmWriteMsr64 (
   UINT32 HighData;
   BOOLEAN Flag;
 
-  LowData  = (UINT32)(Value);
-  HighData = (UINT32)(Value >> 32);
-
   Flag = FilterBeforeMsrWrite (Index, );
   if (Flag) {
+LowData  = (UINT32)(Value);
+HighData = (UINT32)(Value >> 32);
 __asm__ __volatile__ (
   "wrmsr"
   :
-- 
2.31.1



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

[edk2-devel] [PATCH v1 0/1] Fix AsmReadMsr64() and AsmWriteMsr64() with GCC toolchain

[Takuto Naito]

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

This patch fixes the problems of AsmReadMsr64/AsmWriteMsr64 for the GCC 
toolchain
introduced when RegisterFilterLib support was added.

Patch v1 branch: 
https://github.com/naitaku/edk2/tree/patch/fix_read_msr_with_gcc

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 

Takuto Naito (1):
  Fix AsmReadMsr64() and AsmWriteMsr64() with GCC toolchain

 MdePkg/Library/BaseLib/X64/GccInlinePriv.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
2.31.1



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

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

[Brijesh Singh]

Hi James and Laszlo,

I was planning to work to add the support to reserve the Secrets and
CPUID page in E820 map and then create the EFI configuration table entry
for it so that guest OS can reach to it. We have two packages
"SecretDxe" and "SecretPei" in OvmfPkg/AmdSev. Any issues if I use them
in the OvmfPkg.dsc ? Here is what I was thinking:

1) Rename the PcdSevLaunchSecretBase -> PcdSevSecretsBase

2) When SNP is enabled then VMM use this page as secrets page for the SNP

3) When SEV or SEV-ES is enabled then VMM uses this page as a launch
secret page

This will allow me to drop PcdOvmfSnpSecretsBase. This will not just
save 4-bytes but also minimize the code duplication.

Thoughts ?

-Brijesh

On 3/24/21 10:31 AM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
>
> During the SEV-SNP guest launch sequence, two special pages need to
> be inserted, the secrets page and cpuid page. The secrets page,
> contain the VM platform communication keys. The guest BIOS and OS
> can use this key to communicate with the SEV firmware to get the
> attestation report. The Cpuid page, contain the CPUIDs entries
> filtered through the AMD-SEV firmware.
>
> The VMM will locate the secrets and cpuid page addresses through a
> fixed GUID and pass them to SEV firmware to populate further.
> For more information about the page content, see the SEV-SNP spec.
>
> To simplify the pre-validation range calculation in the next patch,
> the CPUID and Secrets pages are moved to the start of the
> MEMFD_BASE_ADDRESS.
>
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/OvmfPkg.dec  |  8 +++
>  OvmfPkg/OvmfPkgX64.fdf   | 24 
>  OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 19 
>  OvmfPkg/ResetVector/ResetVector.inf  |  4 
>  OvmfPkg/ResetVector/ResetVector.nasmb|  2 ++
>  5 files changed, 48 insertions(+), 9 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 4348bb45c6..062926772d 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -317,6 +317,14 @@
>gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|0x0|UINT32|0x42
>gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43
>  
> +  ## The base address of the CPUID page used by SEV-SNP
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpCpuidBase|0|UINT32|0x48
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpCpuidSize|0|UINT32|0x49
> +
> +  ## The base address of the Secrets page used by SEV-SNP
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|0|UINT32|0x50
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize|0|UINT32|0x51
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index d519f85328..ea214600be 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -67,27 +67,33 @@ ErasePolarity = 1
>  BlockSize = 0x1
>  NumBlocks = 0xD0
>  
> -0x00|0x006000
> +0x00|0x001000
> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpCpuidSize
> +
> +0x001000|0x001000
> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
> +
> +0x002000|0x006000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>  
> -0x006000|0x001000
> +0x008000|0x001000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
>  
> -0x007000|0x001000
> +0x009000|0x001000
>  
> gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>  
> -0x008000|0x001000
> +0x00A000|0x001000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
>  
> -0x009000|0x002000
> +0x00B000|0x002000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>  
> -0x00B000|0x001000
> -gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
> -
> -0x00C000|0x001000
> +0x00D000|0x001000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
>  
> +0x00F000|0x001000
> +gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
> +
>  0x01|0x01
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>  
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> index 9c0b5853a4..5456f02924 100644
> --- 

Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

[James Bottomley]

On Mon, 2021-04-12 at 11:54 +, Yao, Jiewen wrote:
> I totally agree with you that from security perspective, the best
> idea to isolate AMD SEV/Intel TDX from standard OVMF.

There's a big difference between building tuned binaries and separating
the subsystems entirely.  Ideally we don't want customers running
images to have to build them differently for Intel or AMD (a bit like
how QEMU/KVM hide the VM differences from users), and Confidential
Computing shares a huge amount of interface similarity, so we wouldn't
want that separated.  I think the rule should be that if both Intel and
AMD expose a feature in different ways, OVMF tries to expose a uniform
API for that feature over two differing implementations.

> Do you want to propose move AMD SEV support to another SEC?

You mean have an entirely separate SEC for AMD, OVMF and Intel?  I
really wouldn't do that: much that's in the SEC: page table setup,
memory mapping and decompression is common to all of them.  This all
follows for a lot of the components.

To build separate binaries, we just need separate dsc and fdf files. 
Then I think the goal would be to share as much as possible to avoid
duplicating the maintenance and possibly diverging the user API.

James




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

[edk2-devel] [PATCH v3 2/7] MdePkg: Allow PcdFSBClock to by Dynamic

[Anthony PERARD via groups.io]

We are going to want to change the value of PcdFSBClock at run time in
OvmfXen, so move it to the PcdsDynamic section.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Liming Gao 
---

Notes:
CC: Michael D Kinney 
CC: Liming Gao 
CC: Zhiguang Liu 

 MdePkg/MdePkg.dec | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index f4156920e599..8965e903e093 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2265,10 +2265,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule]
   # @ValidList  0x8001 | 8, 16, 32
   gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d
 
-  ## This value is used to configure X86 Processor FSB clock.
-  # @Prompt FSB Clock.
-  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
-
   ## The maximum printable number of characters. UefLib functions: 
AsciiPrint(), AsciiErrorPrint(),
   #  PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD value 
to print characters.
   # @Prompt Maximum Printable Number of Characters.
@@ -2372,5 +2368,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # @Prompt Boot Timeout (s)
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x002c
 
+  ## This value is used to configure X86 Processor FSB clock.
+  # @Prompt FSB Clock.
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
+
 [UserExtensions.TianoCore."ExtraFiles"]
   MdePkgExtra.uni
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v3 0/7] OvmfXen: Set PcdFSBClock at runtime

[Anthony PERARD via groups.io]

Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v3

Changes in v3:
- typos and codying style

Changes in v2:
- main change is to allow mapping of Xen pages outside of the RAM
  see patch: "OvmfPkg/XenPlatformPei: Map extra physical address"
- that new function allows to map the Xen shared info page (where we can find
  information about tsc frequency) at the highest physical address allowed.

Hi,

OvmfXen uses the APIC timer, but with an hard-coded frequency that may change
as pointed out here:
  https://edk2.groups.io/g/devel/message/45185
  <20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger>

This series changes that so the frequency is calculated at runtime.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490

There is also one cleanup patch that has nothing to do with the rest.

Cheers,

Anthony PERARD (7):
  OvmfPkg/XenResetVector: Silent a warning from nasm
  MdePkg: Allow PcdFSBClock to by Dynamic
  OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to
XEN_VCPU_TIME_INFO
  OvmfPkg/IndustryStandard: Introduce PageTable.h
  OvmfPkg/XenPlatformPei: Map extra physical address
  OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
  OvmfPkg/OvmfXen: Set PcdFSBClock

 MdePkg/MdePkg.dec |   8 +-
 OvmfPkg/OvmfXen.dsc   |   4 +-
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   4 +
 .../IndustryStandard/PageTable.h} | 117 +---
 OvmfPkg/Include/IndustryStandard/Xen/xen.h|  17 +-
 .../BaseMemEncryptSevLib/X64/VirtualMemory.h  | 143 +-
 OvmfPkg/XenPlatformPei/Platform.h |  10 +
 OvmfPkg/XenPlatformPei/Platform.c |   1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 252 ++
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm|   2 +-
 10 files changed, 287 insertions(+), 271 deletions(-)
 copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h => 
Include/IndustryStandard/PageTable.h} (60%)

-- 
Anthony PERARD



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

[edk2-devel] [PATCH v3 5/7] OvmfPkg/XenPlatformPei: Map extra physical address

[Anthony PERARD via groups.io]

Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.

While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G guest page table
into 4k pages and thus reducing performance of the guest when it
accesses its memory. Also mapping a page like the shared info page and
then unmapping it or mapping it somewhere else would leave a hole in
the RAM that the guest would propably not be able to use anymore.

So the patch introduces a new function which can be used to 1:1
mapping of guest physical memory above 4G during the PEI phase so we
can map the Xen shared pages outside of memory that can be used by
guest, and as high as possible.

Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- fix typos
v2:
- new patch

 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |  1 +
 OvmfPkg/XenPlatformPei/Platform.h |  5 ++
 OvmfPkg/XenPlatformPei/Xen.c  | 71 +++
 3 files changed, 77 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 0ef77db92c03..8790d907d3ec 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 7661f4a8de0a..e70ca58078eb 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -127,6 +127,11 @@ XenGetE820Map (
   UINT32 *Count
   );
 
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+  IN EFI_PHYSICAL_ADDRESS AddressToMap
+  );
+
 extern EFI_BOOT_MODE mBootMode;
 
 extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c41fecdc486e..b2a7d1c21dac 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -17,6 +17,8 @@
 //
 // The Library classes this module consumes
 //
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -386,3 +389,71 @@ InitializeXen (
 
   return EFI_SUCCESS;
 }
+
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+  IN EFI_PHYSICAL_ADDRESS   AddressToMap
+  )
+{
+  INTNIndex;
+  PAGE_MAP_AND_DIRECTORY_POINTER  *L4, *L3;
+  PAGE_TABLE_ENTRY*PageTable;
+
+  DEBUG ((DEBUG_INFO, "Mapping 1:1 of address 0x%lx\n", (UINT64)AddressToMap));
+
+  // L4 / Top level Page Directory Pointers
+
+  L4 = (VOID*)(UINTN)PcdGet32 (PcdOvmfSecPageTablesBase);
+  Index = PML4_OFFSET (AddressToMap);
+
+  if (!L4[Index].Bits.Present) {
+L3 = AllocatePages (1);
+if (L3 == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (L3, EFI_PAGE_SIZE);
+
+L4[Index].Bits.ReadWrite = 1;
+L4[Index].Bits.Accessed = 1;
+L4[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)L3 >> 12;
+L4[Index].Bits.Present = 1;
+  }
+
+  // L3 / Next level Page Directory Pointers
+
+  L3 = (VOID*)(EFI_PHYSICAL_ADDRESS)(L4[Index].Bits.PageTableBaseAddress << 
12);
+  Index = PDP_OFFSET (AddressToMap);
+
+  if (!L3[Index].Bits.Present) {
+PageTable = AllocatePages (1);
+if (PageTable == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (PageTable, EFI_PAGE_SIZE);
+
+L3[Index].Bits.ReadWrite = 1;
+L3[Index].Bits.Accessed = 1;
+L3[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)PageTable >> 
12;
+L3[Index].Bits.Present = 1;
+  }
+
+  // L2 / Page Table Entries
+
+  PageTable = 
(VOID*)(EFI_PHYSICAL_ADDRESS)(L3[Index].Bits.PageTableBaseAddress << 12);
+  Index = PDE_OFFSET (AddressToMap);
+
+  if (!PageTable[Index].Bits.Present) {
+PageTable[Index].Bits.ReadWrite = 1;
+PageTable[Index].Bits.Accessed = 1;
+PageTable[Index].Bits.Dirty = 1;
+PageTable[Index].Bits.MustBe1 = 1;
+PageTable[Index].Bits.PageTableBaseAddress = AddressToMap >> 21;
+PageTable[Index].Bits.Present = 1;
+  }
+
+  CpuFlushTlb ();
+
+  return EFI_SUCCESS;
+}
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v3 7/7] OvmfPkg/OvmfXen: Set PcdFSBClock

[Anthony PERARD via groups.io]

Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.

Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules run before XenPlatformPei.

XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
  using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei

Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.

A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v3:
- cast Freq in assert
- fix typos
- use correct assert to check Status
v2:
- keep the default value of PcdFSBClock because that is part of the syntax.

 OvmfPkg/OvmfXen.dsc   | 4 +---
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 4 
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 86abe277c349..e535503e385d 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -447,9 +447,6 @@ [PcdsFixedAtBuild]
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
-  ## Xen vlapic's frequence is 100 MHz
-  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
-
   # We populate DXE IPL tables with 1G pages preferably on Xen
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable|TRUE
 
@@ -476,6 +473,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
 
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 
   # Set video resolution for text setup.
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5732d2188871..87dd4b24679a 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -85,6 +85,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
 
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 8b06bebd7731..2dc9f9ff8f3c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -632,5 +632,9 @@ CalibrateLapicTimer (
   Freq = DivU64x64Remainder (Dividend, TscTick2 - TscTick, NULL);
   DEBUG ((DEBUG_INFO, "APIC Freq % 8lu Hz\n", Freq));
 
+  ASSERT ((UINT32)Freq <= MAX_UINT32);
+  Status = PcdSet32S (PcdFSBClock, Freq);
+  ASSERT_EFI_ERROR (Status);
+
   UnmapXenPage (SharedInfo);
 }
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v3 6/7] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency

[Anthony PERARD via groups.io]

Calculate the frequency of the APIC timer that Xen provides.

Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.

Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).

The shared_info page is mapped at the highest physical address allowed
as it doesn't need to be in the RAM, thus there's a call to update the
page table.

The calculated frequency is only logged in this patch, it will be used
in a following patch.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
CC: Roger Pau Monné 

v3:
- fix debug format strings
- fix coding style

v2:
- fix CamelCases
- Use U64 multiplication and division helpers
- don't read TscShift from the SharedInfo page again
- change the location of the shared info page to be outside of the ram
- check for overflow in XenDelay
- check for overflow when calculating the calculating APIC frequency

 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   2 +
 OvmfPkg/XenPlatformPei/Platform.h |   5 +
 OvmfPkg/XenPlatformPei/Platform.c |   1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 177 ++
 4 files changed, 185 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 8790d907d3ec..5732d2188871 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
   DebugLib
   HobLib
   IoLib
+  LocalApicLib
   PciLib
   ResourcePublicationLib
   PeiServicesLib
@@ -59,6 +60,7 @@ [LibraryClasses]
   MtrrLib
   MemEncryptSevLib
   PcdLib
+  SafeIntLib
   XenHypercallLib
 
 [Pcd]
diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index e70ca58078eb..77d88fc159d7 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -132,6 +132,11 @@ PhysicalAddressIdentityMapping (
   IN EFI_PHYSICAL_ADDRESS AddressToMap
   );
 
+VOID
+CalibrateLapicTimer (
+  VOID
+  );
+
 extern EFI_BOOT_MODE mBootMode;
 
 extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
b/OvmfPkg/XenPlatformPei/Platform.c
index 717fd0ab1a45..e9511eb40c62 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -448,6 +448,7 @@ InitializeXenPlatform (
   InitializeRamRegions ();
 
   InitializeXen ();
+  CalibrateLapicTimer ();
 
   if (mBootMode != BOOT_ON_S3_RESUME) {
 ReserveEmuVariableNvStore ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b2a7d1c21dac..8b06bebd7731 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -21,8 +21,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -457,3 +459,178 @@ PhysicalAddressIdentityMapping (
 
   return EFI_SUCCESS;
 }
+
+STATIC
+EFI_STATUS
+MapSharedInfoPage (
+  IN VOID *PagePtr
+  )
+{
+  xen_add_to_physmap_t  Parameters;
+  INTN  ReturnCode;
+
+  Parameters.domid = DOMID_SELF;
+  Parameters.space = XENMAPSPACE_shared_info;
+  Parameters.idx = 0;
+  Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+  ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, );
+  if (ReturnCode != 0) {
+return EFI_NO_MAPPING;
+  }
+  return EFI_SUCCESS;
+}
+
+STATIC
+VOID
+UnmapXenPage (
+  IN VOID *PagePtr
+  )
+{
+  xen_remove_from_physmap_t Parameters;
+  INTN  ReturnCode;
+
+  Parameters.domid = DOMID_SELF;
+  Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+  ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, );
+  ASSERT (ReturnCode == 0);
+}
+
+
+STATIC
+UINT64
+GetCpuFreq (
+  IN XEN_VCPU_TIME_INFO *VcpuTime
+  )
+{
+  UINT32 Version;
+  UINT32 TscToSystemMultiplier;
+  INT8   TscShift;
+  UINT64 CpuFreq;
+
+  do {
+Version = VcpuTime->Version;
+MemoryFence ();
+TscToSystemMultiplier = VcpuTime->TscToSystemMultiplier;
+TscShift = VcpuTime->TscShift;
+MemoryFence ();
+  } while (((Version & 1) != 0) && (Version != VcpuTime->Version));
+
+  CpuFreq = DivU64x32 (LShiftU64 (10ULL, 32), TscToSystemMultiplier);
+  if (TscShift >= 0) {
+  CpuFreq = RShiftU64 (CpuFreq, TscShift);
+  } else {
+  CpuFreq = LShiftU64 (CpuFreq, -TscShift);
+  }
+  return CpuFreq;
+}
+
+STATIC
+VOID
+XenDelay (
+  IN XEN_VCPU_TIME_INFO *VcpuTimeInfo,
+  IN UINT64 DelayNs
+  )
+{
+  UINT64Tick;
+  UINT64CpuFreq;
+  UINT64Delay;
+  UINT64DelayTick;
+  UINT64NewTick;
+  RETURN_STATUS 

[edk2-devel] [PATCH v3 3/7] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO

[Anthony PERARD via groups.io]

We are going to use new fields from the Xen headers. Apply the EDK2
coding style so that the code that is going to use it doesn't look out
of place.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- fix case of Tsc* field

 OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h 
b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
index e55d93263285..79a4e212e7c2 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
@@ -183,10 +183,10 @@ struct vcpu_time_info {
  * The correct way to interact with the version number is similar to
  * Linux's seqlock: see the implementations of read_seqbegin/read_seqretry.
  */
-UINT32 version;
+UINT32 Version;
 UINT32 pad0;
-UINT64 tsc_timestamp;   /* TSC at last update of time vals.  */
-UINT64 system_time; /* Time, in nanosecs, since boot.*/
+UINT64 TscTimestamp;   /* TSC at last update of time vals.  */
+UINT64 SystemTime; /* Time, in nanosecs, since boot.*/
 /*
  * Current system time:
  *   system_time +
@@ -194,11 +194,11 @@ struct vcpu_time_info {
  * CPU frequency (Hz):
  *   ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
  */
-UINT32 tsc_to_system_mul;
-INT8   tsc_shift;
+UINT32 TscToSystemMultiplier;
+INT8   TscShift;
 INT8   pad1[3];
 }; /* 32 bytes */
-typedef struct vcpu_time_info vcpu_time_info_t;
+typedef struct vcpu_time_info XEN_VCPU_TIME_INFO;
 
 struct vcpu_info {
 /*
@@ -234,7 +234,7 @@ struct vcpu_info {
 #endif /* XEN_HAVE_PV_UPCALL_MASK */
 xen_ulong_t evtchn_pending_sel;
 struct arch_vcpu_info arch;
-struct vcpu_time_info time;
+struct vcpu_time_info Time;
 }; /* 64 bytes (x86) */
 #ifndef __XEN__
 typedef struct vcpu_info vcpu_info_t;
@@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t;
  * of this structure remaining constant.
  */
 struct shared_info {
-struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
+struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS];
 
 /*
  * A domain can create "event channels" on which it can send and receive
@@ -299,6 +299,7 @@ struct shared_info {
 };
 #ifndef __XEN__
 typedef struct shared_info shared_info_t;
+typedef struct shared_info XEN_SHARED_INFO;
 #endif
 
 /* Turn a plain number into a C UINTN constant. */
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v3 1/7] OvmfPkg/XenResetVector: Silent a warning from nasm

[Anthony PERARD via groups.io]

To avoid nasm generating a warning, replace the macro by the value
expected to be stored in eax.
  Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds

Reported-by: Laszlo Ersek 
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index 2df0f12e18cb..c761e9d30729 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -73,7 +73,7 @@ xenPVHMain:
 ;
 ; parameter for Flat32SearchForBfvBase
 ;
-mov eax, ADDR_OF(fourGigabytes)
+mov eax, 0   ; ADDR_OF(fourGigabytes)
 add eax, edx ; add delta
 
 ;
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v3 4/7] OvmfPkg/IndustryStandard: Introduce PageTable.h

[Anthony PERARD via groups.io]

We are going to use the page table structure in yet another place,
collect the types and macro that can be used from another module
rather than making yet another copy.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Acked-by: Tom Lendacky 
---

Notes:
CC: Brijesh Singh 

v3:
- fix typos and coding style

v2:
- new patch

 .../IndustryStandard/PageTable.h} | 117 +-
 .../BaseMemEncryptSevLib/X64/VirtualMemory.h  | 143 +-
 2 files changed, 5 insertions(+), 255 deletions(-)
 copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h => 
Include/IndustryStandard/PageTable.h} (60%)

diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h 
b/OvmfPkg/Include/IndustryStandard/PageTable.h
similarity index 60%
copy from OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
copy to OvmfPkg/Include/IndustryStandard/PageTable.h
index 996f94f07ebb..5e797eeea8ef 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
+++ b/OvmfPkg/Include/IndustryStandard/PageTable.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Virtual Memory Management Services to set or clear the memory encryption bit
+  x86_64 Page Tables structures
 
   Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
   Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
@@ -11,17 +11,10 @@
 
 **/
 
-#ifndef __VIRTUAL_MEMORY__
-#define __VIRTUAL_MEMORY__
+#ifndef PAGE_TABLE_H_
+#define PAGE_TABLE_H_
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define SYS_CODE64_SEL 0x38
+#include 
 
 #pragma pack(1)
 
@@ -165,106 +158,4 @@ typedef union {
 #define PTE_OFFSET(x)   ( (x >> 12) & PAGETABLE_ENTRY_MASK)
 #define PAGING_1G_ADDRESS_MASK_64   0x000FC000ull
 
-#define PAGE_TABLE_POOL_ALIGNMENT   BASE_2MB
-#define PAGE_TABLE_POOL_UNIT_SIZE   SIZE_2MB
-#define PAGE_TABLE_POOL_UNIT_PAGES  \
-  EFI_SIZE_TO_PAGES (PAGE_TABLE_POOL_UNIT_SIZE)
-#define PAGE_TABLE_POOL_ALIGN_MASK  \
-  (~(EFI_PHYSICAL_ADDRESS)(PAGE_TABLE_POOL_ALIGNMENT - 1))
-
-typedef struct {
-  VOID*NextPool;
-  UINTN   Offset;
-  UINTN   FreePages;
-} PAGE_TABLE_POOL;
-
-/**
-  Return the pagetable memory encryption mask.
-
-  @return  The pagetable memory encryption mask.
-
-**/
-UINT64
-EFIAPI
-InternalGetMemEncryptionAddressMask (
-  VOID
-  );
-
-/**
-  This function clears memory encryption bit for the memory region specified by
-  PhysicalAddress and Length from the current page table context.
-
-  @param[in]  Cr3BaseAddress  Cr3 Base Address (if zero then use
-  current CR3)
-  @param[in]  PhysicalAddress The physical address that is the start
-  address of a memory region.
-  @param[in]  Length  The length of memory region
-  @param[in]  Flush   Flush the caches before applying the
-  encryption mask
-
-  @retval RETURN_SUCCESS  The attributes were cleared for the
-  memory region.
-  @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
-  @retval RETURN_UNSUPPORTED  Clearing the memory encyrption attribute
-  is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryDecrypted (
-  IN  PHYSICAL_ADDRESSCr3BaseAddress,
-  IN  PHYSICAL_ADDRESSPhysicalAddress,
-  IN  UINTN   Length,
-  IN  BOOLEAN Flush
-  );
-
-/**
-  This function sets memory encryption bit for the memory region specified by
-  PhysicalAddress and Length from the current page table context.
-
-  @param[in]  Cr3BaseAddress  Cr3 Base Address (if zero then use
-  current CR3)
-  @param[in]  PhysicalAddress The physical address that is the start
-  address of a memory region.
-  @param[in]  Length  The length of memory region
-  @param[in]  Flush   Flush the caches before applying the
-  encryption mask
-
-  @retval RETURN_SUCCESS  The attributes were set for the memory
-  region.
-  @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
-  @retval RETURN_UNSUPPORTED  Setting the memory encyrption attribute
-  is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryEncrypted (
-  IN  PHYSICAL_ADDRESSCr3BaseAddress,
-  IN  PHYSICAL_ADDRESSPhysicalAddress,
-  IN  UINTN   Length,
-  IN  BOOLEAN Flush
-  );
-
-/**
-  Returns the encryption state of the specified virtual address range.
-
-  @param[in]  Cr3BaseAddress  Cr3 Base Address (if zero then use
-   

Re: [edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Pete Batard]

Hi Sunny,

Functionaly, I see no issues with this patch, and it's indeed a good 
solution to the problem of trying to satisfy everyone while fixing the 
issues we are seeing.


There are however a few minor typos and whitespace issues, that I'm 
detailing below. So could you please send a v2 to address these?


On 2021.04.12 10:05, Sunny Wang wrote:

This is a fix for https://github.com/pftf/RPi4/issues/114.

Changes:
   1. Add a setup option called Boot Policy and consume the setting
  during boot to whether perform or skip ConnectAll.
   2. The Default setting is set to Full discovery because it is not
  worth enabling Fast boot by default on RaspberryPi systems.
  Enabling it just saves boot time about 1 second, but caused a
  lot of issues.

Testing Done:
   - Booted to Standalone UEFI shell on SD card and use drivers
 command to check the result with Fast Boot and Full discovery
 settings. Then, child/device handles are created as expected.

Note and to-do items:
   - The root cause looks like that boot loaders and some tools like
 grub and iPXE haven't supported selective connect/Fast boot.
 However, system firmware should still provide a setup option for
 user to enable Fast boot with old version boot loaders and tools
 , which is why we proposed this change. We will also report this
 issue to boot loader and tool vendors/open source GitHubs.
   - We Will add more options for connecting specific type devices so
 that we can still have the shortest boot time for all use cases.

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
  .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
  .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
  Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
  .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
  .../PlatformBootManagerLib.inf   |  1 +
  Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
  Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
  Platform/RaspberryPi/RaspberryPi.dec |  2 ++
  10 files changed, 80 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 22f86d4d44..d3c5869949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -1,6 +1,6 @@
  /** @file

   *

- *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.

+ *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.

   *  Copyright (c) 2018 - 2020, Andrei Warkentin 

   *

   *  SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -281,6 +281,15 @@ SetupVariables (
  );

}

  


+  Size = sizeof (UINT32);

+  Status = gRT->GetVariable (L"BootPolicy",

+  ,

+  NULL, , );

+  if (EFI_ERROR (Status)) {

+Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));

+ASSERT_EFI_ERROR (Status);

+  }

+

Size = sizeof (UINT32);

Status = gRT->GetVariable (L"SdIsArasan",

,

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index d51e54e010..032e40b0c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
  #

  #  Component description file for the RasbperryPi DXE platform config driver.

  #

-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.

+#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.

  #  Copyright (c) 2018 - 2020, Andrei Warkentin 

  #

  #  SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -93,6 +93,7 @@
gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB

gRaspberryPiTokenSpaceGuid.PcdFanOnGpio

gRaspberryPiTokenSpaceGuid.PcdFanTemp

+  gRaspberryPiTokenSpaceGuid.PcdBootPolicy

  


  [Depex]

gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..7b14fdf39f 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -1,7 +1,7 @@
  /** @file

   *

   *  Copyright (c) 2018, Andrei Warkentin 

- *  Copyright (c) 2020, ARM Limited. All rights reserved.

+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.

   *

   *  SPDX-License-Identifier: BSD-2-Clause-Patent

   *

@@ -60,6 +60,14 @@
  #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"

  #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 

Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

[Yao, Jiewen]

I totally agree with you that from security perspective, the best idea to 
isolate AMD SEV/Intel TDX from standard OVMF.

Do you want to propose move AMD SEV support to another SEC?

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Dr. David
> Alan Gilbert
> Sent: Monday, April 12, 2021 4:35 PM
> To: Laszlo Ersek 
> Cc: Yao, Jiewen ; Xu, Min M ;
> devel@edk2.groups.io; thomas.lenda...@amd.com; j...@linux.ibm.com;
> Brijesh Singh ; Justen, Jordan L
> ; Ard Biesheuvel ;
> Paolo Bonzini ; Nathaniel McCallum
> 
> Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg:
> Reserve the Secrets and Cpuid page for the SEV-SNP guest]
> 
> * Laszlo Ersek (ler...@redhat.com) wrote:
> > On 04/09/21 15:44, Yao, Jiewen wrote:
> > > Hi Laszlo
> > > Thanks.
> > >
> > > We did provide a separate binary in the beginning - see
> https://github.com/tianocore/edk2-staging/tree/TDVF, with same goal - easy to
> maintain and develop. A clean solution, definitely.
> > >
> > > However, we got requirement to deliver one binary solution together with 
> > > 1)
> normal OVMF, 2) AMD-SEV, 3) Intel-TDX.
> > > Now, we are struggling to merge them..
> > >
> > > For DXE, we hope to isolate TDX driver whenever it is possible.
> > > But we only have one reset vector here. Sigh...
> >
> > Can we please pry a little bit at that "one binary" requirement?
> >
> > Ultimately the "guest bundle" is going to be composed by much
> > higher-level code, I expect (such as some userspace code, written in
> > python or similar); selecting a firmware binary in such an environment
> > is surely easier than handling this "polymorphism" in the most
> > restrictive software environment imaginable (reset vector assembly code
> > in the guest)?
> 
> I think also there's a security argument here; some people like to
> measure security in kloc's; so having your secure boot image as small
> as possible for the environment you're actually running does make some
> sense, which favours the 2 image idea.
> 
> Dave
> 
> > Thanks
> > Laszlo
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73950): https://edk2.groups.io/g/devel/message/73950
Mute This Topic: https://groups.io/mt/81969494/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 V2 6/6] Platform/Sgi: add SMMU and timer entries to memory description table

[Sami Mujawar]

Hi Pranav,

Can you sort the PCDs in alphabetical order in the inf, dec and dsc.inc, please?
With that changed.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 06:36, "Pranav Madhu"  wrote:

Add PCDs for base address and address space size for generic timer and
SMMU controllers. Use those PCDs to add platform memory map entries. The
ServerReady SBSA tests, when executed, accesses these controllers and so
the memory mapping for generic timer and SMMU controllers are required.

In addition to this, PCDs for watchdog timer controller base address and
size are introduced instead of using macros for the same. This allows
the base address and address space size for watchdog timer controller to
be specified by platform description files.

Signed-off-by: Pranav Madhu 
---
 Platform/ARM/SgiPkg/SgiPlatform.dec  | 14 -
 Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc |  4 +++
 Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc|  4 +++
 Platform/ARM/SgiPkg/SgiPlatform.dsc.inc  | 10 ++
 Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf  | 11 +++
 Platform/ARM/SgiPkg/Include/SgiPlatform.h|  4 ---
 Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c | 32 
+---
 7 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
b/Platform/ARM/SgiPkg/SgiPlatform.dec
index 86ead241a67c..5c10c6f1635c 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dec
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
@@ -57,11 +57,23 @@
   gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x|UINT64|0x000E
   gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x0|UINT64|0x000F

-  # Timer & Watchdog interrupts
+  # Counter, Timer and Watchdog
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadBase|0|UINT32|0x0015
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadSize|0|UINT32|0x0016
[SAMI] Please sort PCDs in alphabetical order in inf, dec, and dsc.inc.
[/SAMI]
   gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|0|UINT32|0x0011
   gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|0|UINT32|0x0012
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Base|0|UINT32|0x0017
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Size|0|UINT32|0x0018
+  gArmSgiTokenSpaceGuid.PcdTimerControlBase|0|UINT32|0x0019
+  gArmSgiTokenSpaceGuid.PcdTimerControlSize|0|UINT32|0x001A
+  gArmSgiTokenSpaceGuid.PcdWdogBase|0|UINT32|0x001B
+  gArmSgiTokenSpaceGuid.PcdWdogSize|0|UINT32|0x001C
   gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|0|UINT32|0x0013
   gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|0|UINT32|0x0014

+  # SMMU
+  gArmSgiTokenSpaceGuid.PcdSmmuBase|0|UINT32|0x001D
+  gArmSgiTokenSpaceGuid.PcdSmmuSize|0|UINT32|0x001E
+
 [Ppis]
   gNtFwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 
0x9b, 0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
index efbb013b0b60..d3d650323891 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
@@ -50,3 +50,7 @@
   gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|91
   gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|93
   gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|94
+
+  # SMMU
+  gArmSgiTokenSpaceGuid.PcdSmmuBase|0x4F00
+  gArmSgiTokenSpaceGuid.PcdSmmuSize|0x0100
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
index 1167f1a6ff9d..c593156e17be 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
@@ -50,3 +50,7 @@
   gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|108
   gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|110
   gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|111
+
+  # SMMU
+  gArmSgiTokenSpaceGuid.PcdSmmuBase|0x4000
+  gArmSgiTokenSpaceGuid.PcdSmmuSize|0x1000
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
index 12a8f8884c89..e59a399690c1 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
@@ -152,6 +152,16 @@
   # Ethernet / Virtio Network
   gArmSgiTokenSpaceGuid.PcdVirtioNetSize|0x1

+  # Counter, Timer and Watchdog
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadBase|0x2A80
+  gArmSgiTokenSpaceGuid.PcdTimerCounterReadSize|0x0001
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Base|0x2A83
+  gArmSgiTokenSpaceGuid.PcdTimerBase0Size|0x0001
+  gArmSgiTokenSpaceGuid.PcdTimerControlBase|0x2A81
+  gArmSgiTokenSpaceGuid.PcdTimerControlSize|0x0001
+  gArmSgiTokenSpaceGuid.PcdWdogBase|0x2A44
+  gArmSgiTokenSpaceGuid.PcdWdogSize|0x0002

Re: [edk2-devel] [edk2-platforms][PATCH V2 5/6] Platform/Sgi: define PCD for timer interrupt numbers

[Sami Mujawar]

Hi Pranav,

This patch looks good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 06:36, "Pranav Madhu"  wrote:

The generic timer and watchdog timer interrupt numbers on the RD-N2
platform is different than those on the other platforms supported by
SgiPkg. So in order to reuse the existing GTDT ACPI table for all the
supported platforms including RD-N2, introduce and use PCD to provide
the interrupt numbers for watchdog and generic timers.

Signed-off-by: Pranav Madhu 
---
 Platform/ARM/SgiPkg/SgiPlatform.dec | 6 ++
 Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc| 6 ++
 Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc   | 6 ++
 Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdN2AcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf   | 4 
 Platform/ARM/SgiPkg/AcpiTables/RdV1McAcpiTables.inf | 4 
 Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf | 4 
 Platform/ARM/SgiPkg/AcpiTables/Gtdt.aslc| 8 
 11 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
b/Platform/ARM/SgiPkg/SgiPlatform.dec
index 3f0d38a013f2..86ead241a67c 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dec
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
@@ -57,5 +57,11 @@
   gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x|UINT64|0x000E
   gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x0|UINT64|0x000F

+  # Timer & Watchdog interrupts
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|0|UINT32|0x0011
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|0|UINT32|0x0012
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|0|UINT32|0x0013
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|0|UINT32|0x0014
+
 [Ppis]
   gNtFwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 
0x9b, 0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
index e423a6b50c91..efbb013b0b60 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap.dsc.inc
@@ -44,3 +44,9 @@
   gArmTokenSpaceGuid.PcdPciMmio64Base|0x50
   gArmTokenSpaceGuid.PcdPciMmio64Size|0x30
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x6000
+
+  # Timer & Watchdog interrupts
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|92
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|91
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|93
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|94
diff --git a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc 
b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
index 41291eddfe74..1167f1a6ff9d 100644
--- a/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiMemoryMap2.dsc.inc
@@ -44,3 +44,9 @@
   gArmTokenSpaceGuid.PcdPciMmio64Base|0x40
   gArmTokenSpaceGuid.PcdPciMmio64Size|0x40
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x101000
+
+  # Timer & Watchdog interrupts
+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv|109
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv|108
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv|110
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv|111
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
index 7ebd70b197a6..2dd2275665a2 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
@@ -50,11 +50,15 @@
   gArmTokenSpaceGuid.PcdPciBusMin
   gArmTokenSpaceGuid.PcdPciBusMax

+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv
+  gArmSgiTokenSpaceGuid.PcdGtFrame1Gsiv
   gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSize
   gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt
   gArmSgiTokenSpaceGuid.PcdVirtioNetBaseAddress
   gArmSgiTokenSpaceGuid.PcdVirtioNetSize
   gArmSgiTokenSpaceGuid.PcdVirtioNetInterrupt
+  gArmSgiTokenSpaceGuid.PcdWdogWS0Gsiv
+  gArmSgiTokenSpaceGuid.PcdWdogWS1Gsiv

   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
index 2d4354f33018..22e33239070b 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
@@ -50,11 +50,15 @@
   gArmTokenSpaceGuid.PcdPciBusMin
   gArmTokenSpaceGuid.PcdPciBusMax

+  gArmSgiTokenSpaceGuid.PcdGtFrame0Gsiv
+  

Re: [edk2-devel] [edk2-platforms][PATCH V2 3/6] Platform/Sgi: fix CPU acpi-id for RD-V1-MC platform

[Sami Mujawar]

Hi Pranav,

Thank you for this patch.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 06:36, "Pranav Madhu"  wrote:

Fix the incorrect ACPI _UID (Unique ID) object for CPU devices listed
for the RD-V1-MC platform.

Signed-off-by: Pranav Madhu 
---
 Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc | 24 ++--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc
index 0da56ed2a39b..9b3e4f2be370 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Madt.aslc
@@ -69,55 +69,55 @@ STATIC EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE 
Madt = {

 // Chip 1
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core0
-  0, 0, GET_MPID(0x0100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 4, GET_MPID(0x0100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core1
-  0, 1, GET_MPID(0x01000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 5, GET_MPID(0x01000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core2
-  0, 2, GET_MPID(0x01000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 6, GET_MPID(0x01000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core3
-  0, 3, GET_MPID(0x01000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 7, GET_MPID(0x01000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),

 // Chip 2
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core0
-  0, 0, GET_MPID(0x0200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 8, GET_MPID(0x0200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core1
-  0, 1, GET_MPID(0x02000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 9, GET_MPID(0x02000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core2
-  0, 2, GET_MPID(0x02000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 10, GET_MPID(0x02000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core3
-  0, 3, GET_MPID(0x02000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 11, GET_MPID(0x02000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),

 // Chip 3
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core0
-  0, 0, GET_MPID(0x0300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 12, GET_MPID(0x0300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core1
-  0, 1, GET_MPID(0x03000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 13, GET_MPID(0x03000100ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core2
-  0, 2, GET_MPID(0x03000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 14, GET_MPID(0x03000200ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
 EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Zeus core3
-  0, 3, GET_MPID(0x03000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
+  0, 15, GET_MPID(0x03000300ULL, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
   FixedPcdGet32 (PcdGicDistributorBase),
   0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
   },
-- 
2.17.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You 

Re: [edk2-devel] [edk2-platforms][PATCH V2 2/6] Platform/Sgi: fix the list of CPU devices on RD-V1-MC platform

[Sami Mujawar]

Hi Pranav,

Thank you for this patch.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 06:36, "Pranav Madhu"  wrote:

RD-V1-MC platform has four CPUs in each of its four coherently connected
chips. So remove a incorrect CPU device entry in DSDT table that lists a
additional non-existent CPU.

Signed-off-by: Pranav Madhu 
---
 Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl
index aef6473857b0..9bf57d05a646 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl
@@ -109,11 +109,5 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
"ARMSGI",
   Name (_UID, 15)
   Name (_STA, 0xF)
 }
-
-Device (CP16) { // Zeus core 16
-  Name (_HID, "ACPI0007")
-  Name (_UID, 16)
-  Name (_STA, 0xF)
-}
   } // Scope(_SB)
 }
-- 
2.17.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73946): https://edk2.groups.io/g/devel/message/73946
Mute This Topic: https://groups.io/mt/81769417/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] UefiCpuPkg/CpuTimerLib: Update LIBRARY_CLASS of Base instance.

[Laszlo Ersek]

On 04/12/21 05:09, Ni, Ray wrote:
> Laszlo,
> This is also related to CpuTimerLib. I assume that you won't have any concern 
> if I merge today
> 
> We need the INF change very urgently because with the removal of 
> DxeCpuTimerLib, DXE module must use
> BaseCpuTImerLib but the INF doesn't allow it.

Sure, please go ahead.

Thanks
Laszlo

> 
> Thanks,
> Ray
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
>> Sent: Monday, April 12, 2021 10:02 AM
>> To: Lou, Yun ; devel@edk2.groups.io
>> Cc: Dong, Eric ; Laszlo Ersek ;
>> Kumar, Rahul1 
>> Subject: Re: [edk2-devel] [PATCH v1] UefiCpuPkg/CpuTimerLib: Update
>> LIBRARY_CLASS of Base instance.
>>
>> Reviewed-by: Ray Ni 
>>
>>> -Original Message-
>>> From: Lou, Yun 
>>> Sent: Saturday, April 10, 2021 11:23 PM
>>> To: devel@edk2.groups.io
>>> Cc: Lou, Yun ; Ni, Ray ; Dong, Eric
>>> ; Laszlo Ersek ; Kumar, Rahul1
>>> 
>>> Subject: [PATCH v1] UefiCpuPkg/CpuTimerLib: Update LIBRARY_CLASS of
>>> Base instance.
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2832
>>>
>>> Update LIBRARY_CLASS of BaseCpuTimerLib to remove the usage limitation,
>>> otherwise the Base instance cannot be used in some types of modules.
>>>
>>> Signed-off-by: Jason Lou 
>>> Cc: Ray Ni 
>>> Cc: Eric Dong 
>>> Cc: Laszlo Ersek 
>>> Cc: Rahul Kumar 
>>> ---
>>>  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
>>> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
>>> index fd93adc5f1..de0648de91 100644
>>> --- a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
>>> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
>>> @@ -4,7 +4,7 @@
>>>  #  Provides basic timer support using CPUID Leaf 0x15 XTAL frequency. The
>>> performance
>>>
>>>  #  counter features are provided by the processors time stamp counter.
>>>
>>>  #
>>>
>>> -#  Copyright (c) 2019, Intel Corporation. All rights reserved.
>>>
>>> +#  Copyright (c) 2021, Intel Corporation. All rights reserved.
>>>
>>>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>>>
>>>  #
>>>
>>>  ##
>>>
>>> @@ -15,7 +15,7 @@
>>>FILE_GUID  = F10B5B91-D15A-496C-B044-B5235721AA08
>>>
>>>MODULE_TYPE= BASE
>>>
>>>VERSION_STRING = 1.0
>>>
>>> -  LIBRARY_CLASS  = TimerLib|SEC PEI_CORE PEIM
>>>
>>> +  LIBRARY_CLASS  = TimerLib
>>>
>>>MODULE_UNI_FILE= BaseCpuTimerLib.uni
>>>
>>>
>>>
>>>  [Sources]
>>>
>>> --
>>> 2.28.0.windows.1
>>
>>
>>
>> 
>>
> 



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

Re: [edk2-devel] [PATCH] DynamicTablesPkg: add validation for PcdNonBsaCompliant16550SerialHid

[Sami Mujawar]

Hi Joey,

Can you confirm that your sign-off ID is correct, please?
Otherwise this patch looks good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73944): https://edk2.groups.io/g/devel/message/73944
Mute This Topic: https://groups.io/mt/81966375/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 V2 7/7] Platform/ARM/Morello: Add virtio net support

[Sami Mujawar]

Hi Chandni,

This patch looks good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 15:36, "Chandni Cherukuri"  wrote:

This patch registers a virtio net device for Morello
FVP platform.

Signed-off-by: Chandni Cherukuri 
---
 Platform/ARM/Morello/MorelloPlatform.dec|  6 ++
 Platform/ARM/Morello/MorelloPlatformFvp.dsc |  7 +++
 Platform/ARM/Morello/MorelloPlatformFvp.fdf |  6 ++
 Platform/ARM/Morello/Drivers/PlatformDxe/PlatformDxeFvp.inf |  2 +
 Platform/ARM/Morello/Include/Guid/MorelloVirtioDevicesFormSet.h |  3 +
 Platform/ARM/Morello/Drivers/PlatformDxe/VirtioDevices.c| 58 

 6 files changed, 82 insertions(+)

diff --git a/Platform/ARM/Morello/MorelloPlatform.dec 
b/Platform/ARM/Morello/MorelloPlatform.dec
index 9a674593cb3c..6f5c1c1b59fc 100644
--- a/Platform/ARM/Morello/MorelloPlatform.dec
+++ b/Platform/ARM/Morello/MorelloPlatform.dec
@@ -55,6 +55,12 @@
   gArmMorelloTokenSpaceGuid.PcdPciMmio64Translation|0x0|UINT64|0x0017
   
gArmMorelloTokenSpaceGuid.PcdPciExpressBaseAddress|0x2000|UINT64|0x0018

+  # Virtio Net device
+  
gArmMorelloTokenSpaceGuid.PcdVirtioNetBaseAddress|0x|UINT32|0x0019
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetSize|0x|UINT32|0x001A
+  
gArmMorelloTokenSpaceGuid.PcdVirtioNetInterrupt|0x|UINT32|0x001B
+
 [PcdsFeatureFlag.common]
   gArmMorelloTokenSpaceGuid.PcdRamDiskSupported|FALSE|BOOLEAN|0x0007
   gArmMorelloTokenSpaceGuid.PcdVirtioBlkSupported|FALSE|BOOLEAN|0x0008
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetSupported|FALSE|BOOLEAN|0x001C
diff --git a/Platform/ARM/Morello/MorelloPlatformFvp.dsc 
b/Platform/ARM/Morello/MorelloPlatformFvp.dsc
index 35e02be5d5ab..e579fb917348 100644
--- a/Platform/ARM/Morello/MorelloPlatformFvp.dsc
+++ b/Platform/ARM/Morello/MorelloPlatformFvp.dsc
@@ -47,6 +47,7 @@

 [PcdsFeatureFlag.common]
   gArmMorelloTokenSpaceGuid.PcdVirtioBlkSupported|TRUE
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetSupported|TRUE

 [PcdsFixedAtBuild.common]
   # Virtio Disk
@@ -54,8 +55,14 @@
   gArmMorelloTokenSpaceGuid.PcdVirtioBlkSize|0x200
   gArmMorelloTokenSpaceGuid.PcdVirtioBlkInterrupt|128

+  # Virtio Net
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetBaseAddress|0x1C18
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetSize|0x200
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetInterrupt|134
+
 [Components.common]
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
+  OvmfPkg/VirtioNetDxe/VirtioNet.inf

   # Platform driver
   Platform/ARM/Morello/Drivers/PlatformDxe/PlatformDxeFvp.inf
diff --git a/Platform/ARM/Morello/MorelloPlatformFvp.fdf 
b/Platform/ARM/Morello/MorelloPlatformFvp.fdf
index dc3eccd2f3ba..851ee3159b3d 100644
--- a/Platform/ARM/Morello/MorelloPlatformFvp.fdf
+++ b/Platform/ARM/Morello/MorelloPlatformFvp.fdf
@@ -120,6 +120,12 @@ READ_LOCK_STATUS   = TRUE
   # Virtio Block Device support
   INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

+  # Networking stack
+  !include NetworkPkg/Network.fdf.inc
+
+  # Virtio Net support
+  INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
+
   # FAT filesystem + GPT/MBR partitioning
   INF FatPkg/EnhancedFatDxe/Fat.inf
   INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
diff --git a/Platform/ARM/Morello/Drivers/PlatformDxe/PlatformDxeFvp.inf 
b/Platform/ARM/Morello/Drivers/PlatformDxe/PlatformDxeFvp.inf
index e4882343fc77..c36c62f05a39 100644
--- a/Platform/ARM/Morello/Drivers/PlatformDxe/PlatformDxeFvp.inf
+++ b/Platform/ARM/Morello/Drivers/PlatformDxe/PlatformDxeFvp.inf
@@ -34,11 +34,13 @@
 [FeaturePcd]
   gArmMorelloTokenSpaceGuid.PcdRamDiskSupported
   gArmMorelloTokenSpaceGuid.PcdVirtioBlkSupported
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetSupported

 [FixedPcd]
   gArmMorelloTokenSpaceGuid.PcdRamDiskBase
   gArmMorelloTokenSpaceGuid.PcdRamDiskSize
   gArmMorelloTokenSpaceGuid.PcdVirtioBlkBaseAddress
+  gArmMorelloTokenSpaceGuid.PcdVirtioNetBaseAddress

 [Depex]
   gEfiRamDiskProtocolGuid
diff --git 
a/Platform/ARM/Morello/Include/Guid/MorelloVirtioDevicesFormSet.h 
b/Platform/ARM/Morello/Include/Guid/MorelloVirtioDevicesFormSet.h
index 77adffbfd984..b8bd40c104a2 100644
--- a/Platform/ARM/Morello/Include/Guid/MorelloVirtioDevicesFormSet.h
+++ b/Platform/ARM/Morello/Include/Guid/MorelloVirtioDevicesFormSet.h
@@ -11,4 +11,7 @@
 #define MORELLO_VIRTIO_BLOCK_GUID  \
   { 0x2B6E62D0, 0x9346, 0x4E1A, { 0xAA, 0x1E, 0xCB, 0x01, 0xC3, 0x23, 
0x4A, 0x00 } }

+#define MORELLO_VIRTIO_NET_GUID  \
+  { 0x4B428575, 0xD09B, 0x45EE, { 0xAC, 0x91, 0xB1, 0x36, 0xBE, 0xD6, 
0x70, 0x2B } }
+
 #endif 

Re: [edk2-devel] [edk2-platforms][PATCH V2 5/7] Platform/ARM/Morello: Add initial support for Morello Platform

[Sami Mujawar]

Hi Chandni,

This patch looks good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 15:36, "Chandni Cherukuri"  wrote:

From: Anurag Koul 

This patch adds the initial support for Morello FVP platform.

Co-authored-by: Chandni Cherukuri 
Signed-off-by: Chandni Cherukuri 
---
 Platform/ARM/Morello/MorelloPlatform.dec |  60 
 Platform/ARM/Morello/MorelloPlatform.dsc.inc | 236 +++
 Platform/ARM/Morello/MorelloPlatformFvp.dsc  |  61 
 Platform/ARM/Morello/MorelloPlatformFvp.fdf  | 303 
 4 files changed, 660 insertions(+)

diff --git a/Platform/ARM/Morello/MorelloPlatform.dec 
b/Platform/ARM/Morello/MorelloPlatform.dec
new file mode 100644
index ..9a674593cb3c
--- /dev/null
+++ b/Platform/ARM/Morello/MorelloPlatform.dec
@@ -0,0 +1,60 @@
+## @file
+#  Describes the entire platform configuration.
+#
+#  Copyright (c) 2021, ARM Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = Morello
+  PACKAGE_GUID   = F09A2C11-7864-4B1D-869E-03EE2AD79288
+  PACKAGE_VERSION= 0.1
+

+
+#
+# Include Section - list of Include Paths that are provided by this 
package.
+#   Comments are used for Keywords and Module Types.
+#

+
+[Includes.common]
+  Include# Root include for the package
+
+[Guids.common]
+  gArmMorelloTokenSpaceGuid =  { 0x0A8C3A78, 0xA56F, 0x4788, { 0x83, 0xB4, 
0xCD, 0x29, 0x62, 0x96, 0x77, 0x51 } }
+
+[PcdsFixedAtBuild]
+  # Ramdisk
+  gArmMorelloTokenSpaceGuid.PcdRamDiskBase|0x8800|UINT32|0x0001
+  gArmMorelloTokenSpaceGuid.PcdRamDiskSize|0x1800|UINT32|0x0002
+
+  # Secondary DDR memory
+  gArmMorelloTokenSpaceGuid.PcdDramBlock2Base|0|UINT64|0x0003
+
+  # Virtio Block device
+  
gArmMorelloTokenSpaceGuid.PcdVirtioBlkBaseAddress|0x|UINT32|0x0004
+  gArmMorelloTokenSpaceGuid.PcdVirtioBlkSize|0x|UINT32|0x0005
+  
gArmMorelloTokenSpaceGuid.PcdVirtioBlkInterrupt|0x|UINT32|0x0006
+
+  # PCIe
+  gArmMorelloTokenSpaceGuid.PcdPciBusMin|0|UINT32|0x0009
+  gArmMorelloTokenSpaceGuid.PcdPciBusMax|15|UINT32|0x000A
+  gArmMorelloTokenSpaceGuid.PcdPciBusCount|16|UINT32|0x000B
+  gArmMorelloTokenSpaceGuid.PcdPciIoBase|0x0|UINT32|0x000C
+  gArmMorelloTokenSpaceGuid.PcdPciIoSize|0x0080|UINT32|0x000D
+  gArmMorelloTokenSpaceGuid.PcdPciIoMaxBase|0x007F|UINT32|0x000E
+  
gArmMorelloTokenSpaceGuid.PcdPciIoTranslation|0x6780|UINT32|0x000F
+  gArmMorelloTokenSpaceGuid.PcdPciMmio32Base|0x6000|UINT32|0x0010
+  gArmMorelloTokenSpaceGuid.PcdPciMmio32Size|0x0780|UINT32|0x0011
+  
gArmMorelloTokenSpaceGuid.PcdPciMmio32MaxBase|0x677F|UINT32|0x0012
+  gArmMorelloTokenSpaceGuid.PcdPciMmio32Translation|0x0|UINT32|0x0013
+  gArmMorelloTokenSpaceGuid.PcdPciMmio64Base|0x9|UINT64|0x0014
+  gArmMorelloTokenSpaceGuid.PcdPciMmio64Size|0x20|UINT64|0x0015
+  
gArmMorelloTokenSpaceGuid.PcdPciMmio64MaxBase|0x28|UINT64|0x0016
+  gArmMorelloTokenSpaceGuid.PcdPciMmio64Translation|0x0|UINT64|0x0017
+  
gArmMorelloTokenSpaceGuid.PcdPciExpressBaseAddress|0x2000|UINT64|0x0018
+
+[PcdsFeatureFlag.common]
+  gArmMorelloTokenSpaceGuid.PcdRamDiskSupported|FALSE|BOOLEAN|0x0007
+  gArmMorelloTokenSpaceGuid.PcdVirtioBlkSupported|FALSE|BOOLEAN|0x0008
diff --git a/Platform/ARM/Morello/MorelloPlatform.dsc.inc 
b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
new file mode 100644
index ..dccd22248318
--- /dev/null
+++ b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
@@ -0,0 +1,236 @@
+## @file
+#  Component description file for Morello Platform
+#
+#  Copyright (c) 2021, ARM Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[LibraryClasses.common]
+  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
+  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
+  ArmPlatformLib|Platform/ARM/Morello/Library/PlatformLib/PlatformLib.inf
+  BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
+
+  # Ramdisk Support
+  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
+

Re: [edk2-devel] [edk2-platforms][PATCH V2 6/7] Platform-ARM-Morello: Add Readme.md file

[Sami Mujawar]

Hi Chandni,

Thank you for this patch.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 01/04/2021, 15:36, "Chandni Cherukuri"  wrote:

This patch adds Readme.md file for Morello Platform.
The document consists of information regarding the platform,
steps to build and boot till UEFI Shell on the Morello FVP
Platform.

Signed-off-by: Chandni Cherukuri 
---
 Platform/ARM/Morello/Readme.md | 46 
 1 file changed, 46 insertions(+)

diff --git a/Platform/ARM/Morello/Readme.md b/Platform/ARM/Morello/Readme.md
new file mode 100644
index ..8d441234f3b8
--- /dev/null
+++ b/Platform/ARM/Morello/Readme.md
@@ -0,0 +1,46 @@
+# Introduction
+
+Morello is an ARMv8-A platform that implements the capability architecture
+extension. Capability architecture specific changes will be added 
[here](https://git.morello-project.org/morello).
+
+The platform port in UEFI firmware provides ARMv8-A architecture 
enablement.
+
+Platform code is located at Platform/ARM/Morello.
+
+# Documentation
+
+Further information on Morello Platform is available at this 
[page](https://developer.arm.com/architectures/cpu-architecture/a-profile/morello).
+
+# Morello FVP
+
+Morello FVP can be downloaded from this 
[location](https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps).
+
+# Supported Host and Toolchain
+
+- Host PC should be running Ubuntu Linux 18.04 LTS.
+- Please refer to the `edk2-platforms/Readme.md` for downloading the GCC 
toolchain.
+
+# Build Instructions
+
+Please refer to the `edk2-platforms/Readme.md` for build instructions.
+
+# Dependencies
+
+Once the FVP is running, the SCP will be the first to boot and will bring 
the AP
+core out of reset. The AP core will start executing Trusted Firmware-A at 
BL31
+and once it completes the execution, it will start executing UEFI.
+
+The SCP and TF-A binaries are required to boot to the UEFI Shell.
+
+## SCP Firmware
+
+The SCP firmware source code can be downloaded from this 
[page](https://github.com/ARM-software/SCP-firmware).
+
+Refer to the [SCP 
Readme](https://github.com/ARM-software/SCP-firmware/blob/master/user_guide.md)
+for building SCP firmware.
+
+## Trusted Firmware-A (TF-A)
+
+The Trusted Firmware-A source code can be downloaded from this 
[page](https://trustedfirmware-a.readthedocs.io/en/latest/).
+
+Refer to the [TF-A 
Readme](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/arm/morello/index.rst?h=refs/heads/master)
 for building TF-A.
-- 
2.17.1




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

[edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Sunny Wang]

This is a fix for https://github.com/pftf/RPi4/issues/114.

Changes:
  1. Add a setup option called Boot Policy and consume the setting
 during boot to whether perform or skip ConnectAll.
  2. The Default setting is set to Full discovery because it is not
 worth enabling Fast boot by default on RaspberryPi systems.
 Enabling it just saves boot time about 1 second, but caused a
 lot of issues.

Testing Done:
  - Booted to Standalone UEFI shell on SD card and use drivers
command to check the result with Fast Boot and Full discovery
settings. Then, child/device handles are created as expected.

Note and to-do items:
  - The root cause looks like that boot loaders and some tools like
grub and iPXE haven't supported selective connect/Fast boot.
However, system firmware should still provide a setup option for
user to enable Fast boot with old version boot loaders and tools
, which is why we proposed this change. We will also report this
issue to boot loader and tool vendors/open source GitHubs.
  - We Will add more options for connecting specific type devices so
that we can still have the shortest boot time for all use cases.

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
 .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
 Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
 .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
 .../PlatformBootManagerLib.inf   |  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
 Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
 Platform/RaspberryPi/RaspberryPi.dec |  2 ++
 10 files changed, 80 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 22f86d4d44..d3c5869949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -1,6 +1,6 @@
 /** @file
  *
- *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
  *  Copyright (c) 2018 - 2020, Andrei Warkentin 
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -281,6 +281,15 @@ SetupVariables (
 );
   }
 
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"BootPolicy",
+  ,
+  NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));
+ASSERT_EFI_ERROR (Status);
+  }
+
   Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"SdIsArasan",
   ,
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index d51e54e010..032e40b0c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
 #
 #  Component description file for the RasbperryPi DXE platform config driver.
 #
-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
 #  Copyright (c) 2018 - 2020, Andrei Warkentin 
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -93,6 +93,7 @@
   gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
   gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
+  gRaspberryPiTokenSpaceGuid.PcdBootPolicy
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..7b14fdf39f 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -1,7 +1,7 @@
 /** @file
  *
  *  Copyright (c) 2018, Andrei Warkentin 
- *  Copyright (c) 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
  *
@@ -60,6 +60,14 @@
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
+#string STR_BOOT_POLICY_PROMPT#language en-US "Boot Policy"
+#string STR_BOOT_POLICY_HELP  #language en-US "When Fast Boot is 
selected, only required devices will be discoverd for reducing "
+  "the boot time."
+  "When Full Discovery is 
selected, all the devices will be discoverd for some "
+

[edk2-devel] [PATCH] IntelSiliconPkg/ShadowMicrocode: Fix build failure

[Ni, Ray]

The commit 7e4c6f982a0accd5aa86337b46d20199db989aeb
updated ShadowMicrocode module to consume MicrocodeLib.

But the change caused the build failure.

The patch fixed the build failure and also verified the change
in real platform.

Signed-off-by: Ray Ni 
Cc: Rangasai V Chaganty 
---
 .../Feature/ShadowMicrocode/ShadowMicrocodePei.c   | 3 +--
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c
index 4e4b69a0ca..7f4a3f8fbd 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodePei.c
@@ -291,7 +291,6 @@ ShadowMicrocode (
   UINTN MaxPatchNumber;
   CPU_MICROCODE_HEADER  *MicrocodeEntryPoint;
   UINTN PatchCount;
-  UINTN DataSize;
   UINTN TotalSize;
   UINTN TotalLoadSize;
 
@@ -342,7 +341,7 @@ ShadowMicrocode (
 if (FitEntry[Index].Type == FIT_TYPE_01_MICROCODE) {
   MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (UINTN) 
FitEntry[Index].Address;
   TotalSize = GetMicrocodeLength (MicrocodeEntryPoint);
-  if (IsValidMicrocode (MicrocodeEntryPoint, TotalSize, MicrocodeCpuId, 
CpuIdCount, FALSE)) {
+  if (IsValidMicrocode (MicrocodeEntryPoint, TotalSize, 0, MicrocodeCpuId, 
CpuIdCount, FALSE)) {
 PatchInfoBuffer[PatchCount].Address = (UINTN) MicrocodeEntryPoint;
 PatchInfoBuffer[PatchCount].Size= TotalSize;
 TotalLoadSize += TotalSize;
diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
index edc79c9b9c..5e0de7e19a 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
@@ -39,6 +39,7 @@
   
MicrocodeFlashAccessLib|IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.inf
   
PeiGetVtdPmrAlignmentLib|IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  MicrocodeLib|UefiCpuPkg/Library/MicrocodeLib/MicrocodeLib.inf
 
 [LibraryClasses.common.PEIM]
   PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
-- 
2.27.0.windows.1



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

Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

[Dr. David Alan Gilbert]

* Laszlo Ersek (ler...@redhat.com) wrote:
> On 04/09/21 15:44, Yao, Jiewen wrote:
> > Hi Laszlo
> > Thanks.
> > 
> > We did provide a separate binary in the beginning - see 
> > https://github.com/tianocore/edk2-staging/tree/TDVF, with same goal - easy 
> > to maintain and develop. A clean solution, definitely.
> > 
> > However, we got requirement to deliver one binary solution together with 1) 
> > normal OVMF, 2) AMD-SEV, 3) Intel-TDX.
> > Now, we are struggling to merge them..
> > 
> > For DXE, we hope to isolate TDX driver whenever it is possible.
> > But we only have one reset vector here. Sigh...
> 
> Can we please pry a little bit at that "one binary" requirement?
> 
> Ultimately the "guest bundle" is going to be composed by much
> higher-level code, I expect (such as some userspace code, written in
> python or similar); selecting a firmware binary in such an environment
> is surely easier than handling this "polymorphism" in the most
> restrictive software environment imaginable (reset vector assembly code
> in the guest)?

I think also there's a security argument here; some people like to
measure security in kloc's; so having your secure boot image as small
as possible for the environment you're actually running does make some
sense, which favours the 2 image idea.

Dave

> Thanks
> Laszlo
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



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

Re: [edk2-devel] [PATCH] RedfishPkg/RedfishConfigHandler: EDKII RedfishConfigHandler Protocol

[Nickle Wang]

Reviewed-by: Nickle Wang 

Got it. Thanks Abner.

Nickle

-Original Message-
From: Chang, Abner (HPS SW/FW Technologist)  
Sent: Monday, April 12, 2021 12:20 PM
To: Wang, Nickle (HPS SW) ; devel@edk2.groups.io
Subject: RE: [edk2-devel] [PATCH] RedfishPkg/RedfishConfigHandler: EDKII 
RedfishConfigHandler Protocol

Ah, yes. I will revise the copyrights in Redfish.fdf.inc and 
RedfishComponents.dsc.inc when merge it.
Thanks for catching this.

Abner

> -Original Message-
> From: Wang, Nickle (HPS SW)
> Sent: Monday, April 12, 2021 11:53 AM
> To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> 
> Subject: RE: [edk2-devel] [PATCH] RedfishPkg/RedfishConfigHandler: EDKII
> RedfishConfigHandler Protocol
> 
> Looks good to me. But for the copyright, I think it would be "2020-2021", 
> right?
> For example:
> 
> -# (C) Copyright 2020 Hewlett Packard Enterprise Development LP
> +# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
> 
> Thanks,
> Nickle
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abner
> Chang
> Sent: Friday, March 26, 2021 1:55 PM
> To: devel@edk2.groups.io
> Cc: Wang, Nickle (HPS SW) 
> Subject: [edk2-devel] [PATCH] RedfishPkg/RedfishConfigHandler: EDKII
> RedfishConfigHandler Protocol
> 
> The driver is used to manage EDK2 Redfish Configuration Handler
> Protocol installed by EDK2 Redfish feature drivers.
> This is the EDK2 Redfish client driver written based on the EDK2
> Redfish foundation to initialize EDK2 Redfish feature drivers.
> 
> EDK2 Redfish feature drivers are used to provision/consume/update
> the firmware owns Redfish properties during system power on
> initialization.
> 
> RedfishConfigHandlerCommon.c has the common code for the driver
> instances used in different EDK2 boot phases or used by different
> driver models in the future contribution.
> 
> Signed-off-by: Jiaxin Wu 
> Signed-off-by: Siyuan Fu 
> Signed-off-by: Fan Wang 
> Signed-off-by: Abner Chang 
> 
> Cc: Nickle Wang 
> ---
>  RedfishPkg/RedfishComponents.dsc.inc  |   3 +-
>  RedfishPkg/Redfish.fdf.inc|   3 +-
>  .../RedfishConfigHandlerDriver.inf|  60 ++
>  .../RedfishConfigHandlerCommon.h  | 101 +++
>  .../RedfishConfigHandlerDriver.h  | 159 +
>  .../RedfishConfigHandlerCommon.c  | 265 
>  .../RedfishConfigHandlerDriver.c  | 587 ++
>  7 files changed, 1176 insertions(+), 2 deletions(-)
>  create mode 100644
> RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
>  create mode 100644
> RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerCommon.h
>  create mode 100644
> RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.h
>  create mode 100644
> RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerCommon.c
>  create mode 100644
> RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.c
> 
> diff --git a/RedfishPkg/RedfishComponents.dsc.inc
> b/RedfishPkg/RedfishComponents.dsc.inc
> index 08f1d3bc32..d0116f065c 100644
> --- a/RedfishPkg/RedfishComponents.dsc.inc
> +++ b/RedfishPkg/RedfishComponents.dsc.inc
> @@ -6,7 +6,7 @@
>  # of EDKII Redfish drivers according to the value of flags described in
>  # "RedfishDefines.dsc.inc".
>  #
> -# (C) Copyright 2020 Hewlett Packard Enterprise Development LP
> +# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -17,4 +17,5 @@
>RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.inf
>RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
>RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.inf
> +  RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
>  !endif
> diff --git a/RedfishPkg/Redfish.fdf.inc b/RedfishPkg/Redfish.fdf.inc
> index a64fd119a9..9673246b3f 100644
> --- a/RedfishPkg/Redfish.fdf.inc
> +++ b/RedfishPkg/Redfish.fdf.inc
> @@ -5,7 +5,7 @@
>  # by using "!include RedfishPkg/RedfisLibs.fdf.inc" to specify the module
> instances
>  # to be built in the firmware volume.
>  #
> -# (C) Copyright 2020 Hewlett Packard Enterprise Development LP
> +# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -15,4 +15,5 @@
>INF RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.inf
>INF RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
>INF RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.inf
> +  INF RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
>  !endif
> diff --git a/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
> b/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
> new file mode 100644
> index 00..def91c7531
> --- /dev/null
> +++ b/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
> @@ -0,0 +1,60 @@
> +## @file
> +#  INF file for the UEFI driver model Redfish Configuration Handler
> +#  Driver.
> +#
> +#