date:20220223

[edk2-devel] [PATCH 1/2] MdeModulePkg/SdMmcPciHcDxe: Make timeout for SD card configurable

2022-02-23 Thread Sean Rhodes

The default 1s timeout can delay boot splash on some hardware with no
benefit.

Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Matt DeVillier 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   | 3 ++-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 4 
 MdeModulePkg/MdeModulePkg.dec| 4 
 MdeModulePkg/MdeModulePkg.uni| 4 
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index 85e09cf114..b76c7cffa2 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -24,6 +24,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -49,7 +50,7 @@ extern EDKII_SD_MMC_OVERRIDE  *mOverride;
 //
 // Generic time out value, 1 microsecond as unit.
 //
-#define SD_MMC_HC_GENERIC_TIMEOUT  1 * 1000 * 1000
+#define SD_MMC_HC_GENERIC_TIMEOUT  (PcdGet32 (PcdSdMmcGenericTimeoutValue))
 
 //
 // SD/MMC async transfer timer interval, set by experience.
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
index 453ecde7fd..e502443ddd 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
@@ -56,6 +56,7 @@
   BaseLib
   UefiDriverEntryPoint
   DebugLib
+  PcdLib
 
 [Protocols]
   gEdkiiSdMmcOverrideProtocolGuid   ## SOMETIMES_CONSUMES
@@ -68,3 +69,6 @@
 
 [UserExtensions.TianoCore."ExtraFiles"]
   SdMmcPciHcDxeExtra.uni
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue  ## CONSUMES
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 463e889e9a..40601c9583 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1559,6 +1559,10 @@
   # @Prompt Maximum permitted FwVol section nesting depth (exclusive).
   
gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth|0x10|UINT32|0x0030
 
+  ## Indicates the default timeout value for SD/MMC Host Controller operations 
in microseconds.
+  # @Prompt SD/MMC Host Controller Operations Timeout (us).
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue|100|UINT32|0x0031
+
 [PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## This PCD defines the Console output row. The default value is 25 
according to UEFI spec.
   #  This PCD could be set to 0 then console output would be at max column and 
max row.
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index 27889a7280..b070f15ff2 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1173,6 +1173,10 @@

   " TRUE  - Capsule In Ram is supported."

   " FALSE - Capsule In Ram is not supported."
 
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdSdMmcGenericTimeoutValue_PROMPT 
#language en-US "SD/MMC Host Controller Operations Timeout (us)."
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdSdMmcGenericTimeoutValue_HELP   
#language en-US "Indicates the default timeout value for SD/MMC Host Controller 
operations in microseconds."
+
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdCodRelocationDevPath_PROMPT  
#language en-US "Capsule On Disk relocation device path."
 
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdCodRelocationDevPath_HELP  
#language en-US   "Full device path of platform specific device to store 
Capsule On Disk temp relocation file."
-- 
2.32.0



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

[edk2-devel] [PATCH 2/2] UefiPayloadPkg: Hookup SD/MMC timeout

2022-02-23 Thread Sean Rhodes

Hook SD_MMC_TIMEOUT build option to SdMmcGenericTimeoutValue PCD.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Sean Rhodes 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 1ce96a51c1..23c2787a94 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -33,6 +33,7 @@
   DEFINE UNIVERSAL_PAYLOAD= FALSE
   DEFINE SECURITY_STUB_ENABLE = TRUE
   DEFINE SMM_SUPPORT  = FALSE
+  DEFINE SD_MMC_TIMEOUT   = 100
   #
   # SBL:  UEFI payload for Slim Bootloader
   # COREBOOT: UEFI payload for coreboot
@@ -398,6 +399,7 @@
 !if $(PERFORMANCE_MEASUREMENT_ENABLE)
   gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask   | 0x1
 !endif
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue|$(SD_MMC_TIMEOUT)
 
 [PcdsPatchableInModule.X64]
   gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister|$(RTC_INDEX_REGISTER)
-- 
2.32.0



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

Re: [edk2-devel] [edk2-non-osi][PATCH 1/1] Drivers/Realtek: Including Realtek driver to enable network support

2022-02-23 Thread deepak . pandey

Looks Good to me , has been verified with the internal platforms.

best regards
Deepak


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86954): https://edk2.groups.io/g/devel/message/86954
Mute This Topic: https://groups.io/mt/89187860/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/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms

2022-02-23 Thread Vineel Kovvuri via groups.io

Hi Yi Li,

I have posted the recent patch set to enable ECC ciphers in OpenSSLLib to the 
bug https://bugzilla.tianocore.org/show_bug.cgi?id=3679

I have ran the entire OVMF Azure pipeline locally and confirm that the code 
gets build without any issue. Thanks for the inputs after enlarging DXEFV the 
build succeeded.

I am new to EDK build and to the overall process so please review the patch set 
and provide your comments. I am happy to address them. Once reviewed I can add 
it to the proposed feature to the release planning wiki

0001-Crypto-Enable-ECC-ciphers.patch
0002-Port-VsIntrinsicLib-from-Project-Mu.patch
0003-Reference-VsIntrinsicLib.patch
0004-Increase-FV-size.patch

Thanks,
Vineel


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86953): https://edk2.groups.io/g/devel/message/86953
Mute This Topic: https://groups.io/mt/86257810/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] OvmfPkg: Generate CloudHv as a PVH ELF binary

2022-02-23 Thread Gerd Hoffmann

> > > +DATA = {
> > > +  #
> > > +  # This hex array have been generated by
> > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > +  # and copied manually.
> > 
> > How about having the generator write a .fdf.inc file which you can
> > just
> > include directly without manual copying?
> 
> I understand the idea, but do you have any pointer to some existing
> code in the repo already doing such thing?

I'd suggest to just commit the generated include file to git instead of
hooking the generator call into the build system, i.e. updating it would
still be a manual process, but easier and less error-prone because the
manual copying goes away.

take care,
  Gerd



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

2022-02-23 Thread Gerd Hoffmann

  Hi,

> > Beside that:  The name TdxStartupLib doesn't reflect reality any more, we
> > should give it a better name.
> How about PeilessStartupLib? 

Don't like it too much, but don't have a better idea.
In any case clearly better than TdxStartupLib.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

2022-02-23 Thread Ashish Singhal via groups.io

Hello Ard,

When we had a discussion on this topic earlier, maybe a few weeks back, we 
thought device memory is being accessed in a speculative manner. Our latest 
debug where we focussed on MMU page tables at the time of error tells that the 
issue is actually DRAM mapping in page tables getting corrupt (as per DS-5) 
where descriptor for a page seems to be something garbage. What this causes is 
that a valid input address in DRAM may get translated to an address in a 
different region of DRAM or some address in device memory.

When I invalidate the instruction cache after enabling MMUs, this issue seems 
to be getting resolved. Again, I am not saying this is a fix but this is 
something that solves the issue while we are looking for suggestions from you 
for a proper fix.

I have tried to summarize the problem based on the latest findings a few emails 
down the trail if you want to have a look at that again.

Thanks
Ashish

From: Ard Biesheuvel 
Sent: Wednesday, February 23, 2022 3:54 PM
To: Ashish Singhal 
Cc: edk2-devel-groups-io ; Marc Zyngier 
; Sami Mujawar ; Ard Biesheuvel 
; Leif Lindholm 
Subject: Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU 
Enable

External email: Use caution opening links or attachments

On Wed, 23 Feb 2022 at 19:14, Ashish Singhal  wrote:
>
> Ard,
>
> During PrePi, I setup the initial memory map by calling into ArmConfigureMmu 
> function with my memory table where device memory regions have attribute of 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE and DRAM regions have attribute of 
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK.
>
> For device memory, XN bit is set by ArmMemoryAttributeToPageAttribute 
> function. After PrePi, when I add a region of memory to device memory from a 
> DXE driver, I call gDS->AddMemorySpace with EfiGcdMemoryTypeMemoryMappedIo 
> and EFI_MEMORY_UC | EFI_MEMORY_RUNTIME followed by 
> gDS->SetMemorySpaceAttributes with EFI_MEMORY_UC.
>
> Please let me know in case I have still not understood your question.
>

This all looks ok. But the real question is whether the address that
the speculative access targets is mapped using the XN attribute or
not, so you will need to find a way to check that.

So there are a couple of options:
- The XN attribute is set correctly, but the CPU is speculatively
fetching instructions anyway. This would imply a severe hardware bug,
and flushing the I-cache is unlikely to make a difference.
- The speculative access is not the result of an instruction fetch, in
which case I-cache maintenance is unlikely to help either.
- The XN bit is not being set correctly, and so the MMU code needs to be fixed.

Papering over this by adding I-cache maintenance doesn't seem the best
course of action tbh.

--
Ard.

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

回复: [edk2-devel] [PATCH v2 0/1] MdePkg/Include SMBIOS 3.5.0 changes

2022-02-23 Thread gaoliming

AbduL:
  Sorry for the late response. But, I see your sent patch is empty. Can you
check it?
  
  Please see this link https://edk2.groups.io/g/devel/message/85329

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Attar,
> AbdulLateef (Abdul Lateef) via groups.io
> 发送时间: 2022年2月24日 10:02
> 收件人: devel@edk2.groups.io; Attar, AbdulLateef (Abdul Lateef)
> 
> 抄送: Michael D Kinney ; Liming Gao
> ; Zhiguang Liu 
> 主题: Re: [edk2-devel] [PATCH v2 0/1] MdePkg/Include SMBIOS 3.5.0
> changes
> 
> Hi,
>Gentle reminder, Please review the patch.
> Thanks
> AbduL
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abdul
> Lateef Attar via groups.io
> Sent: Friday, January 7, 2022 7:26 PM
> To: devel@edk2.groups.io
> Cc: Michael D Kinney ; Liming Gao
> ; Zhiguang Liu 
> Subject: [edk2-devel] [PATCH v2 0/1] MdePkg/Include SMBIOS 3.5.0 changes
> 
> [CAUTION: External Email]
> 
> Rebase the patch and fix the uncrustify.
> 
> Reference:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fabdattar%2Fedk2%2Ftree%2Fsmbios_3_5_0_v2data=04%7C
> 01%7CAbdulLateef.Attar%40amd.com%7C4ecac07fa9984365a0dc08d9d1e55
> c29%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63777160590
> 7726617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=83AEIB%2
> BmxsZrv9vXDy%2FcEYRQx30r2dZHqlaiFPnAT4I%3Dreserved=0
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> 
> Abdul Lateef Attar (1):
>   MdePkg/Include: Smbios Specification 3.5.0 changes
> 
>  MdePkg/Include/IndustryStandard/SmBios.h | 144 +++-
>  1 file changed, 140 insertions(+), 4 deletions(-)
> 
> --
> 2.25.1
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 





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

Re: [edk2-devel] [PATCH] MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting

2022-02-23 Thread Wu, Hao A

1 inline comment below:


> -Original Message-
> From: Sean Rhodes 
> Sent: Friday, February 18, 2022 3:30 PM
> To: devel@edk2.groups.io
> Cc: Dong, Guo ; Rhodes, Sean
> ; Wu, Hao A ; Ni, Ray
> ; Matt DeVillier ; Patrick
> Rudolph 
> Subject: [PATCH] MdeModulePkg/Usb/Keyboard.c: Don't request protocol
> before setting
> 
> No need to check the interface protocol then conditionally setting,
> just set it to BOOT_PROTOCOL and check for error.
> 
> This is what Linux does for HID devices as some don't follow the USB spec.
> One example is the Aspeed BMC HID keyboard device, which adds a massive
> boot delay without this patch as it doesn't respond to 'GetProtocolRequest'.
> 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Signed-off-by: Matt DeVillier 
> Signed-off-by: Patrick Rudolph 
> Signed-off-by: Sean Rhodes 
> ---
>  MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c| 17 +
>  .../Library/BrotliCustomDecompressLib/brotli|  2 +-
>  2 files changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
> b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
> index 5a94a4dda7..73b5df2b64 100644
> --- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
> +++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
> @@ -854,22 +854,15 @@ InitUSBKeyboard (
>  }
> 
>}
> 
> 
> 
> -  UsbGetProtocolRequest (
> 
> -UsbKeyboardDevice->UsbIo,
> 
> -UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
> 
> -
> 
> -);
> 
>//
> 
>// Set boot protocol for the USB Keyboard.
> 
>// This driver only supports boot protocol.
> 
>//
> 
> -  if (Protocol != BOOT_PROTOCOL) {
> 
> -UsbSetProtocolRequest (
> 
> -  UsbKeyboardDevice->UsbIo,
> 
> -  UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
> 
> -  BOOT_PROTOCOL
> 
> -  );
> 
> -  }
> 
> +  UsbSetProtocolRequest (
> 
> +UsbKeyboardDevice->UsbIo,
> 
> +UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
> 
> +BOOT_PROTOCOL
> 
> +);
> 
> 
> 
>UsbKeyboardDevice->CtrlOn= FALSE;
> 
>UsbKeyboardDevice->AltOn = FALSE;
> 
> diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> index f4153a09f8..666c3280cc 16
> --- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> +++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> @@ -1 +1 @@
> -Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
> +Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d


Why change in BrotliCustomDecompressLib is needed for this patch?

Best Regards,
Hao Wu


> --
> 2.32.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86948): https://edk2.groups.io/g/devel/message/86948
Mute This Topic: https://groups.io/mt/89228276/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/2] MdeModulePkg/SdMmcPciHcDxe: Make timeout for SD card configurable

2022-02-23 Thread Wu, Hao A

3 inline comments below:


> -Original Message-
> From: Sean Rhodes 
> Sent: Friday, February 18, 2022 3:24 PM
> To: devel@edk2.groups.io
> Cc: Dong, Guo ; Matt DeVillier
> ; Wu, Hao A ; Ni, Ray
> ; Wang, Jian J ; Gao, Liming
> ; Rhodes, Sean 
> Subject: [PATCH 1/2] MdeModulePkg/SdMmcPciHcDxe: Make timeout for
> SD card configurable
> 
> From: Matt DeVillier 
> 
> The default 1s timeout can delay boot splash on some hardware with no
> benefit.
> 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Signed-off-by: Matt DeVillier 
> Signed-off-by: Sean Rhodes 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h| 3 ++-
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf  | 4 
>  MdeModulePkg/Library/BrotliCustomDecompressLib/brotli | 2 +-
>  MdeModulePkg/MdeModulePkg.dec | 4 
>  MdeModulePkg/MdeModulePkg.uni | 4 
>  5 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 85e09cf114..b76c7cffa2 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -24,6 +24,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
> 
>  #include 
> 
>  #include 
> 
> +#include 
> 
> 
> 
>  #include 
> 
>  #include 
> 
> @@ -49,7 +50,7 @@ extern EDKII_SD_MMC_OVERRIDE  *mOverride;
>  //
> 
>  // Generic time out value, 1 microsecond as unit.
> 
>  //
> 
> -#define SD_MMC_HC_GENERIC_TIMEOUT  1 * 1000 * 1000
> 
> +#define SD_MMC_HC_GENERIC_TIMEOUT  (PcdGet32
> (PcdSdMmcGenericTimeoutValue))
> 
> 
> 
>  //
> 
>  // SD/MMC async transfer timer interval, set by experience.
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
> index 453ecde7fd..a9d05736d7 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
> @@ -56,6 +56,7 @@
>BaseLib
> 
>UefiDriverEntryPoint
> 
>DebugLib
> 
> +  PcdLib
> 
> 
> 
>  [Protocols]
> 
>gEdkiiSdMmcOverrideProtocolGuid   ## SOMETIMES_CONSUMES
> 
> @@ -68,3 +69,6 @@
> 
> 
>  [UserExtensions.TianoCore."ExtraFiles"]
> 
>SdMmcPciHcDxeExtra.uni
> 
> +
> 
> +[Pcd.IA32,Pcd.X64]


1. "[Pcd]" should be fine.


> 
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue
>   ## CONSUMES


2. Could you please help to run the PatchCheck.py to check your patch before 
sending out:

py BaseTools/Scripts/PatchCheck.py -1
Checking git commit: HEAD
MdeModulePkg/SdMmcPciHcDxe: Make timeout for SD card configurable
The commit message format passed all checks.
Code format is not valid:
 * Tab character used
   File: MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
   Line:   gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue   
## CONSUMES


> 
> diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> index f4153a09f8..666c3280cc 16
> --- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> +++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> @@ -1 +1 @@
> -Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
> +Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d


3. Why change in BrotliCustomDecompressLib is needed for this patch?


Best Regards,
Hao Wu


> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 463e889e9a..40601c9583 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1559,6 +1559,10 @@
># @Prompt Maximum permitted FwVol section nesting depth (exclusive).
> 
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth|
> 0x10|UINT32|0x0030
> 
> 
> 
> +  ## Indicates the default timeout value for SD/MMC Host Controller
> operations in microseconds.
> 
> +  # @Prompt SD/MMC Host Controller Operations Timeout (us).
> 
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue|1000
> 000|UINT32|0x0031
> 
> +
> 
>  [PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> 
>## This PCD defines the Console output row. The default value is 25
> according to UEFI spec.
> 
>#  This PCD could be set to 0 then console output would be at max column
> and max row.
> 
> diff --git a/MdeModulePkg/MdeModulePkg.uni
> b/MdeModulePkg/MdeModulePkg.uni
> index 27889a7280..b070f15ff2 100644
> --- a/MdeModulePkg/MdeModulePkg.uni
> +++ b/MdeModulePkg/MdeModulePkg.uni
> @@ -1173,6 +1173,10 @@
>   
>  " TRUE  - Capsule In Ram is
> supported."
> 
>   
>  " FALSE - Capsule In Ram is not
> supported."
> 
> 
> 
> +#string
>

Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

2022-02-23 Thread Marc Zyngier

On Wed, 23 Feb 2022 07:02:28 +,
Ard Biesheuvel  wrote:
> 
> (+ Marc)
> 
> On Tue, 22 Feb 2022 at 03:42, Ashish Singhal  wrote:
> >
> > Even with MMU turned off, instruction cache can speculate
> > and fetch instructions. This can cause a crash if region
> > being executed has been modified recently. With this patch,
> > we ensure that instruction cache is invalidated right after
> > MMU has been enabled and any potentially stale instruction
> > fetched earlier has been discarded.

Are you doing code patching while the MMU is off?

> >
> 
> I don't follow this reasoning. Every time the UEFI image loader loads
> an image into memory, it does so with MMU and caches enabled, and the
> code regions are cleaned to the PoU before being invalidated in the
> I-cache. So how could these regions be stale? The only code that needs
> special care here is the little trampoline that executes with the MMU
> off, but this is being taken care of explicitly, by cleaning the code
> to the PoC before invoking it.
>
> > This is specially helpful when the memory attributes of a
> > region in MMU are being changed and some instructions
> > operating on the region are prefetched in the instruction
> > cache.
> >

Huh, this is way too vague. How do you expect anyone to understand
your problem based on this?

> 
> This sounds like a TLB problem not a cache problem. For the sake of
> posterity, could you include a more detailed description of the issue
> in the commit log? IIRC, this is about speculative instruction fetches
> hitting device memory locations?
> 
> As I mentioned before, the architecture does not permit speculative
> instruction fetches for regions mapped with the XN attribute.
> 
> Is the issue occurring under virtualization? Is there a stage 2
> mapping that lacks the XN attribute for the device memory region in
> question?
> 
> > Signed-off-by: Ashish Singhal 
> > ---
> >  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S   | 4 +++-
> >  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 2 ++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> > b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> > index d3cc1e8671..9648245182 100644
> > --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> > +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> > @@ -89,7 +89,9 @@ ASM_FUNC(ArmEnableMmu)
> > dsb nsh
> > isb
> > msr sctlr_el3, x0   // Write back
> > -4: isb
> > +4: ic  iallu
> > +   dsb sy

Why DSB SY? Given that you are only invalidating on a single CPU,
DSB NSH should be enough.

> > +   isb
> > ret
> >
> >
> > diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S 
> > b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > index 66ebca571e..56cc2dd73f 100644
> > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > @@ -37,6 +37,8 @@
> >
> >// re-enable the MMU
> >msr   sctlr_el\el, x8
> > +  iciallu
> > +  dsb   sy

Same thing here.

M.

-- 
Without deviation from the norm, progress is not possible.


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

Re: [edk2-devel] [PATCH v2 0/1] MdePkg/Include SMBIOS 3.5.0 changes

2022-02-23 Thread Attar, AbdulLateef (Abdul Lateef) via groups.io

Hi,
   Gentle reminder, Please review the patch.
Thanks
AbduL

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Abdul Lateef 
Attar via groups.io
Sent: Friday, January 7, 2022 7:26 PM
To: devel@edk2.groups.io
Cc: Michael D Kinney ; Liming Gao 
; Zhiguang Liu 
Subject: [edk2-devel] [PATCH v2 0/1] MdePkg/Include SMBIOS 3.5.0 changes

[CAUTION: External Email]

Rebase the patch and fix the uncrustify.

Reference: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fabdattar%2Fedk2%2Ftree%2Fsmbios_3_5_0_v2data=04%7C01%7CAbdulLateef.Attar%40amd.com%7C4ecac07fa9984365a0dc08d9d1e55c29%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637771605907726617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=83AEIB%2BmxsZrv9vXDy%2FcEYRQx30r2dZHqlaiFPnAT4I%3Dreserved=0

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

Abdul Lateef Attar (1):
  MdePkg/Include: Smbios Specification 3.5.0 changes

 MdePkg/Include/IndustryStandard/SmBios.h | 144 +++-
 1 file changed, 140 insertions(+), 4 deletions(-)

--
2.25.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86945): https://edk2.groups.io/g/devel/message/86945
Mute This Topic: https://groups.io/mt/89357687/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/2] MdePkg/Include: Define new DEBUG_FILE to specify path.

2022-02-23 Thread Guomin Jiang

Hi Kinney, Liming, Zhiguang,

Can you give comments on this patch

Thanks
Guomin

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Guomin
> Jiang
> Sent: Friday, February 18, 2022 10:30 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang 
> Subject: [edk2-devel] [PATCH 2/2] MdePkg/Include: Define new
> DEBUG_FILE to specify path.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3840
> 
> Use DEBUG_FILE to control ASSERT path
> 
> Motivation and Goal:
> 1. The path will occupy many size in DEBUG build when file path is long 2. We
> hope can reduce the size but not impact the debug capability 3. If only use
> filename, we can search the filename to locate file. It
>can save many size meanwhile.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Signed-off-by: Guomin Jiang 
> ---
>  MdePkg/Include/Library/DebugLib.h | 39 ++---
> --
>  1 file changed, 28 insertions(+), 11 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/DebugLib.h
> b/MdePkg/Include/Library/DebugLib.h
> index 8d3d08638d73..5469c6308422 100644
> --- a/MdePkg/Include/Library/DebugLib.h
> +++ b/MdePkg/Include/Library/DebugLib.h
> @@ -8,7 +8,7 @@
>of size reduction when compiler optimization is disabled. If
> MDEPKG_NDEBUG is
>defined, then debug and assert related macros wrapped by it are the NULL
> implementations.
> 
> -Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2022, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -85,6 +85,31 @@ SPDX-License-Identifier: BSD-2-Clause-Patent  #define
> DEBUG_LINE_NUMBER  __LINE__  #endif
> 
> +//
> +// Source file.
> +// Default is use the to compiler provided __FILE__ macro value. The
> +__FILE__ // mapping can be overriden by predefining DEBUG_FILE // //
> +Defining DEBUG_FILE to a fixed value is useful when comparing builds //
> +across machine or configuration with different slash or path // file.
> +//
> +// Another benefit is we can customize the ASSERT path without
> +depending on // compiler ability // // It's for all no matter VS, GCC,
> +CLANG // #ifdef DEBUG_FILE #else #define DEBUG_FILE  __FILE__ #endif
> +
> +// Blow override for keep clang behavior #if defined (__clang__) &&
> +defined (__FILE_NAME__) #undef DEBUG_FILE #define DEBUG_FILE
> +__FILE_NAME__ #endif
> +
>  /**
>Macro that converts a Boolean expression to a Null-terminated ASCII string.
> 
> @@ -337,17 +362,9 @@ UnitTestDebugAssert (
>IN CONST CHAR8  *Description
>);
> 
> -  #if defined (__clang__) && defined (__FILE_NAME__) -#define
> _ASSERT(Expression)  UnitTestDebugAssert (__FILE_NAME__,
> DEBUG_LINE_NUMBER, DEBUG_EXPRESSION_STRING (Expression))
> -  #else
> -#define _ASSERT(Expression)  UnitTestDebugAssert (__FILE__,
> DEBUG_LINE_NUMBER, DEBUG_EXPRESSION_STRING (Expression))
> -  #endif
> +#define _ASSERT(Expression)  UnitTestDebugAssert (DEBUG_FILE,
> +DEBUG_LINE_NUMBER, DEBUG_EXPRESSION_STRING (Expression))
>  #else
> -  #if defined (__clang__) && defined (__FILE_NAME__) -#define
> _ASSERT(Expression)  DebugAssert (__FILE_NAME__,
> DEBUG_LINE_NUMBER, DEBUG_EXPRESSION_STRING (Expression))
> -  #else
> -#define _ASSERT(Expression)  DebugAssert (__FILE__,
> DEBUG_LINE_NUMBER, DEBUG_EXPRESSION_STRING (Expression))
> -  #endif
> +#define _ASSERT(Expression)  DebugAssert (DEBUG_FILE,
> +DEBUG_LINE_NUMBER, DEBUG_EXPRESSION_STRING (Expression))
>  #endif
> 
>  /**
> --
> 2.35.1.windows.2
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86944): https://edk2.groups.io/g/devel/message/86944
Mute This Topic: https://groups.io/mt/89357561/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 8/8] OvmfPkg: Introduce IntelTdxX64 for TDVF Config-B

2022-02-23 Thread Min Xu

Hi
> 
> > +  #
> > +  # Defines for default states.  These can be changed on the command line.
> > +  # -D FLAG=VALUE
> > +  #
> > +  DEFINE SECURE_BOOT_ENABLE  = FALSE
> 
> Will TDX support secure boot?  If not then this config switch can simply be
> dropped (and the checks for SECURE_BOOT_ENABLE too).
Secure boot is supported by TDVF.

Thanks
Min


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86943): https://edk2.groups.io/g/devel/message/86943
Mute This Topic: https://groups.io/mt/89266124/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 7/8] OvmfPkg: Update DxeAcpiTimerLib to read HostBridgeDevId in PlatformInfoHob

2022-02-23 Thread Min Xu

On February 23, 2022 7:04 PM, Gerd Hoffmann wrote:
> 
> >//
> >// Query Host Bridge DID to determine platform type
> > +  // Tdx guest stores the HostBridgePciDevId in a GuidHob.
> > +  // So we first check if this HOB exists
> >//
> > -  HostBridgeDevId = PcdGet16 (PcdOvmfHostBridgePciDevId);
> > +  GuidHob = GetFirstGuidHob ();  if
> > + (GuidHob != NULL) {
> > +PlatformInfo= (EFI_HOB_PLATFORM_INFO *)GET_GUID_HOB_DATA
> (GuidHob);
> > +HostBridgeDevId = PlatformInfo->HostBridgePciDevId;  } else {
> > +HostBridgeDevId = PcdGet16 (PcdOvmfHostBridgePciDevId);  }
> 
> Another thing we can probably simplify when we use a PlatformInfoHob in
> both PEi and PEI-less mode.
Agree.
> 
> > +[Guids]
> > +  gUefiOvmfPkgTdxPlatformGuid  ## CONSUMES
> 
> name this UefiOvmfPkgPlatformInfoGuid ?
Sure. Thanks for the suggestion. It will be renamed in the next version.

Thanks
Min


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

2022-02-23 Thread Min Xu

On February 23, 2022 6:50 PM, Gerd Hoffmann wrote:
> 
> > +EFI_STATUS
> > +EFIAPI
> > +InitializePlatform (
> > +  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> > +  )
> > +{
> 
> > +  Pci64Base = 0;
> > +  Pci64Size = 0;
> > +
> > +  FirstNonAddress   = PlatformGetFirstNonAddress 
> > (,
> , 0x8);
> > +  PlatformInfoHob->PcdPciMmio64Base = Pci64Base;
> > + PlatformInfoHob->PcdPciMmio64Size = Pci64Size;
> 
> I think here are opportunities to make the differences between PEI and PEI-
> less boot even smaller, by:
> 
>   (1) Allocate a PlatformInfoHob also when using PEI boot workflow.
>   (2) Switch PlatformInitLib functions like PlatformGetFirstNonAddress() to
>   receive a PlatformInfoHob pointer so they can update the HOB
>   directly.
>   (3) Add more platform info variables to PlatformInfoHob
>   (FirstNonAddress, PhysMemAddressWidth for example).
> 
> But I guess that kind of improvements can also be done incrementally after
> getting this upstream.  It's also easier to test that kind of changes when we
> have both PEI and PEI-less variants present in the upstream repo.  So I'm fine
> with deferring these changes for now.
Agree. Thanks for your understanding.

> 
> Beside that:  The name TdxStartupLib doesn't reflect reality any more, we
> should give it a better name.
How about PeilessStartupLib? 

Thanks
Min


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86940): https://edk2.groups.io/g/devel/message/86940
Mute This Topic: https://groups.io/mt/89266118/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/2] MdeModulePkg/GraphicsConsoleDxe: Check status to make sure no error

2022-02-23 Thread Guomin Jiang

Hi Liming, Jian, Zhichao, Ray,

Can you help review it?

Thanks
Guomin

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Guomin
> Jiang
> Sent: Tuesday, February 22, 2022 11:41 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Gao, Liming
> ; Gao, Zhichao ; Ni,
> Ray 
> Subject: [edk2-devel] [PATCH 1/2] MdeModulePkg/GraphicsConsoleDxe:
> Check status to make sure no error
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668
> 
> SetMode will fail in some case. for example, without XServer.
> Should handle these case when SetMode fail.
> 
> If we don't handle it, it will Segmentation fault.
> 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Cc: Zhichao Gao 
> Cc: Ray Ni 
> Signed-off-by: Guomin Jiang 
> ---
>  .../Console/GraphicsConsoleDxe/GraphicsConsole.c  | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole
> .c
> b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsol
> e.c
> index 1bdd1b8a6732..07436cbd15bf 100644
> ---
> a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole
> .c
> +++
> b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsol
> e.c
> @@ -1,7 +1,7 @@
>  /** @file
>This is the main routine for initializing the Graphics Console support 
> routines.
> 
> -Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2022, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -518,7 +518,7 @@ GraphicsConsoleControllerDriverStart (
>}
>  }
> 
> -if (ModeNumber != Private->GraphicsOutput->Mode->Mode) {
> +if (EFI_ERROR (Status) || (ModeNumber != Private->GraphicsOutput-
> >Mode->Mode)) {
>//
>// Current graphics mode is not set or is not set to the mode which we
> have found,
>// set the new graphic mode.
> @@ -531,17 +531,6 @@ GraphicsConsoleControllerDriverStart (
>  goto Error;
>}
>  }
> -
> -//
> -// Double confirm SetMode can success
> -//
> -Status = Private->GraphicsOutput->SetMode (Private->GraphicsOutput,
> ModeNumber);
> -if (EFI_ERROR (Status)) {
> -  //
> -  // The mode set operation failed
> -  //
> -  goto Error;
> -}
>} else if (FeaturePcdGet (PcdUgaConsumeSupport)) {
>  //
>  // At first try to set user-defined resolution
> --
> 2.35.1.windows.2
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86939): https://edk2.groups.io/g/devel/message/86939
Mute This Topic: https://groups.io/mt/89355656/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/2] EmulatorPkg/EmuGopDxe: Set ModeInfo after Open successfully

2022-02-23 Thread Guomin Jiang

Hi Fish and Ray,

Can you help review it?

Thanks
Guomin

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Guomin
> Jiang
> Sent: Tuesday, February 22, 2022 11:41 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ni, Ray 
> Subject: [edk2-devel] [PATCH 2/2] EmulatorPkg/EmuGopDxe: Set ModeInfo
> after Open successfully
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2668
> 
> WindowOpen will fail in some case. for example, without XServer.
> 
> Shouldn't set ModeInfo in this case to avoid the caller use it incorrectly
> 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Signed-off-by: Guomin Jiang 
> ---
>  EmulatorPkg/EmuGopDxe/GopScreen.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/EmulatorPkg/EmuGopDxe/GopScreen.c
> b/EmulatorPkg/EmuGopDxe/GopScreen.c
> index 41f748bc6402..ec5ef795d6e5 100644
> --- a/EmulatorPkg/EmuGopDxe/GopScreen.c
> +++ b/EmulatorPkg/EmuGopDxe/GopScreen.c
> @@ -108,10 +108,6 @@ EmuGopSetMode (
>}
> 
>ModeData = 
> >ModeData[ModeNumber];
> -  This->Mode->Mode = ModeNumber;
> -  Private->GraphicsOutput.Mode->Info->HorizontalResolution = ModeData-
> >HorizontalResolution;
> -  Private->GraphicsOutput.Mode->Info->VerticalResolution   = ModeData-
> >VerticalResolution;
> -  Private->GraphicsOutput.Mode->Info->PixelsPerScanLine= ModeData-
> >HorizontalResolution;
> 
>if (Private->HardwareNeedsStarting) {
>  Status = EmuGopStartWindow (
> @@ -128,6 +124,11 @@ EmuGopSetMode (
>  Private->HardwareNeedsStarting = FALSE;
>}
> 
> +  This->Mode->Mode = ModeNumber;
> +  Private->GraphicsOutput.Mode->Info->HorizontalResolution = ModeData-
> >HorizontalResolution;
> +  Private->GraphicsOutput.Mode->Info->VerticalResolution   = ModeData-
> >VerticalResolution;
> +  Private->GraphicsOutput.Mode->Info->PixelsPerScanLine= ModeData-
> >HorizontalResolution;
> +
>Status = Private->EmuGraphicsWindow->Size (
>   Private->EmuGraphicsWindow,
>   ModeData->HorizontalResolution,
> --
> 2.35.1.windows.2
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH V6 34/42] OvmfPkg: Update PlatformPei to support Tdx guest

2022-02-23 Thread Min Xu

OnFebruary 23, 2022 6:14 PM, Gerd Hoffmann wrote:
> > -Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
> > +if (TdIsEnabled ()) {
> > +  Pml4Entries = 0x200;
> > +} else {
> > +  Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
> > +}
> 
> With the PlatformAddressWidthInitialization() update in patch #33 it should
> not be needed to special-case TDX here.  You might need a check for 5-level
> paging support (mPhysMemAddressWidth > 48) though, or just cap
> Pml4Entries at 512 entries.
> 
As we agree in current stage 5-level paging is not supported, I will cap 
Pml4Entries at 512 entries when mPhysMemAddressWidth > 48.

Thanks
Min


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

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Maintainers.txt: update email for Leif Lindholm

2022-02-23 Thread Rebecca Cran


Reviewed-by: Rebecca Cran 

On 2/7/22 05:21, Leif Lindholm wrote:

NUVIA inc. was acquired by Qualcomm in March 2021, but we continued
contributions under the existing IDs until the start of this year.
We are now switching to use Qualcomm Innovation Center email, so
update Maintainers.txt to reflect this.

Cc: Michael D Kinney 
Cc: Leif Lindholm 
Signed-off-by: Leif Lindholm 
---
  Maintainers.txt | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 8dcc34ed0c2e..da6abc7344c2 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -68,7 +68,7 @@ F: */
  EDK II Platforms maintainers
  
  F: *
-M: Leif Lindholm 
+M: Leif Lindholm 
  M: Michael D Kinney 
  
  Responsible Disclosure, Reporting Security Issues

@@ -81,7 +81,7 @@ EDK II Platforms Packages:
  96Boards
  F: Platform/96Boards/
  M: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  AMD Seattle

  F: Platform/AMD/OverdriveBoard/
@@ -89,7 +89,7 @@ F: Platform/LeMaker/CelloBoard/
  F: Platform/SoftIron/
  F: Silicon/AMD/Styx/
  M: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  Ampere Computing

  F: Platform/Ampere
@@ -98,7 +98,7 @@ R: Nhi Pham 
  R: Vu Nguyen 
  R: Thang Nguyen 
  R: Chuong Tran 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  ARM

  F: Platform/ARM/
@@ -111,12 +111,12 @@ BeagleBoard:
  F: Platform/BeagleBoard/
  F: Silicon/TexasInstruments/
  R: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  Comcast

  F: Platform/Comcast/
  M: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  OptionRomPkg

  F: Drivers/OptionRomPkg/
@@ -130,14 +130,14 @@ M: Ilias Apalodimas 
  
  DisplayLink

  F: Drivers/DisplayLink/
-M: Leif Lindholm 
+M: Leif Lindholm 
  M: Ard Biesheuvel 
  R: Andy Hayes 
  
  HiSilicon

  F: Platform/Hisilicon/
  F: Silicon/Hisilicon/
-M: Leif Lindholm 
+M: Leif Lindholm 
  R: Ard Biesheuvel 
  R: Wenyi Xie 
  
@@ -320,26 +320,26 @@ F: Platform/Marvell/

  F: Platform/SolidRun/Armada80x0McBin/
  F: Silicon/Marvell/
  R: Marcin Wojtas 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  Miscellaneous drivers

  F: Silicon/Atmel/
  F: Silicon/Openmoko/
  F: Silicon/Synopsys/DesignWare/
  R: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  
  NXP platforms and silicon

  F: Platform/NXP/
  F: Silicon/NXP/
-M: Leif Lindholm 
+M: Leif Lindholm 
  R: Meenakshi Aggarwal 
  
  QEMU sbsa-ref platform

  F: Platform/Qemu/SbsaQemu/
  F: Silicon/Qemu/SbsaQemu/
  M: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  R: Graeme Gregory 
  R: Radoslaw Biernacki 
  
@@ -347,7 +347,7 @@ Raspberry Pi platforms and silicon

  F: Platform/RaspberryPi/
  F: Silicon/Broadcom/
  M: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  R: Jeremy Linton 
  
  RPMB driver for OP-TEE

@@ -360,7 +360,7 @@ F: Platform/Socionext/
  F: Silicon/NXP/Library/Pcf8563RealTimeClockLib/
  F: Silicon/Socionext/
  M: Ard Biesheuvel 
-M: Leif Lindholm 
+M: Leif Lindholm 
  R: Masami Hiramatsu 
  
  Silicon/RISC-V/ProcessorPkg

@@ -378,7 +378,7 @@ R: Daniel Schaefer 
  Phytium platforms and silicon
  F: Platform/Phytium/
  F: Silicon/silicon/
-M: Leif Lindholm 
+M: Leif Lindholm 
  R: Peng Xie 
  R: Ling Jia 
  R: Yiqi Shu 



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

[edk2-devel][PATCH] Maintainers.txt: Add new reviewer for UefiPayloadPkg

2022-02-23 Thread Guo Dong

From: Guo Dong 

Add Sean Rhodes as UefiPayload reviewer mainly focus on
UEFI payload for coreboot support.

Signed-off-by: Guo Dong 
Cc: Ray Ni 
Cc: Benjamin You 
Cc: Maurice Ma 
Cc: Michael D Kinney 
Cc: Sean Rhodes 
---
 Maintainers.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 924069187e..d26f91c02e 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -601,6 +601,7 @@ M: Guo Dong  [gdong1]
 M: Ray Ni  [niruiyu]
 R: Maurice Ma  [mauricema]
 R: Benjamin You  [BenjaminYou]
+R: Sean Rhodes 
 S: Maintained
 
 UnitTestFrameworkPkg
-- 
2.35.1.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86935): https://edk2.groups.io/g/devel/message/86935
Mute This Topic: https://groups.io/mt/89353894/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/2] UefiPayloadPkg: Hook up RNG support

2022-02-23 Thread Ma, Maurice

Reviewed-by: Maurice Ma 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sean
> Rhodes
> Sent: Wednesday, February 23, 2022 14:44
> To: devel@edk2.groups.io
> Cc: Dong, Guo ; Patrick Rudolph
> ; Yao, Jiewen ;
> Wang, Jian J ; Ni, Ray ; Ma,
> Maurice ; You, Benjamin
> 
> Subject: [edk2-devel] [PATCH 2/2] UefiPayloadPkg: Hook up RNG support
> 
> From: Patrick Rudolph 
> 
> Hoop Up RNG from SecurityPkg.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Guo Dong 
> Cc: Ray Ni 
> Cc: Maurice Ma 
> Cc: Benjamin You 
> Signed-off-by: Patrick Rudolph 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 8 
> UefiPayloadPkg/UefiPayloadPkg.fdf | 4 
>  2 files changed, 12 insertions(+)
> 
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
> b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 1ce96a51c1..0d4b4da24f 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -703,6 +703,14 @@
> 
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.i
> nf !endif +  #+  # Random Number Generator+  #+
> SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf {+
> +
> RngLib|SecurityPkg/Library/BaseRngLib/BaseRngLib.inf+  }+   
> #--
>    #  Build the shell   #--diff --git
> a/UefiPayloadPkg/UefiPayloadPkg.fdf b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index c7b04978ad..6af1a8c8aa 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -229,6 +229,10 @@ INF
> MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
>  # INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf +#
> Random Number Generator+#+INF
> SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf+ # # UEFI
> network modules #--
> 2.32.0
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#86923): https://edk2.groups.io/g/devel/message/86923
> Mute This Topic: https://groups.io/mt/89353219/1773972
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [maurice...@intel.com]
> -=-=-=-=-=-=
> 



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

[edk2-devel] Unit Test and sanitizers

2022-02-23 Thread Andrew Fish via groups.io

Just throwing out an idea for the edk2 unit tests. At least for clang you can 
turn on the sanitizer via a simple command line flag to the compiler. So seems 
it would make sense to turn on it for unit tests? I’m not sure if the Linux 
clang, and maybe even some versions of gcc support this too?  Not clear how it 
works on VC++ or other compilers.

Here is a stupid example from the Xcode clang on macOS of what I’m talking 
about. In the 1st case the write to NULL crashes the test app with a seg fault. 
With the sanitizers the buffer overflow and UB  is detected. So the sanitizer 
gives you better test coverage for free and makes it much easier to root cause 
the failure.

~/work/Compiler/sanitize>cat t.c
  
int
main(int argc, char **argv)
{
  char test[1] = { 0 };
  char *ptr = [0];

#ifndef SKIP_OVERFLOW
  ptr += 2;
  *ptr = 1;
#endif
  
  ptr = (char *)0;
  *ptr = 2;
  return 0;
}
~/work/Compiler/sanitize>clang -g t.c && ./a.out
  
zsh: segmentation fault  ./a.out
~/work/Compiler/sanitize>clang -g -fsanitize=address -fsanitize=undefined  t.c 
&& ./a.out 
=
==5302==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ff7b066f7c2 at pc 0x00010f893db0 bp 0x7ff7b066f790 sp 0x7ff7b066f788
WRITE of size 1 at 0x7ff7b066f7c2 thread T0
#0 0x10f893daf in main t.c:9
#1 0x1129754fd in start dyldMain.cpp:879

Address 0x7ff7b066f7c2 is located in stack of thread T0 at offset 34 in frame
#0 0x10f893baf in main t.c:3

  This frame has 1 object(s):
[32, 33) 'test' (line 4) <== Memory access at offset 34 overflows this 
variable
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow t.c:9 in main
Shadow bytes around the buggy address:
  0x1ffef60cdea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cded0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1ffef60cdef0: 00 00 00 00 f1 f1 f1 f1[01]f3 f3 f3 00 00 00 00
  0x1ffef60cdf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==5302==ABORTING
zsh: abort  ./a.out
~/work/Compiler/sanitize>clang -g -fsanitize=address -fsanitize=undefined 
-DSKIP_OVERFLOW  t.c && ./a.out 
t.c:13:3: runtime error: store to null pointer of type 'char'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior t.c:13:3 in 
AddressSanitizer:DEADLYSIGNAL
=
==5312==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x0001020cde3f bp 0x7ff7bde358c0 sp 0x7ff7bde357c0 T0)
==5312==The signal is caused by a WRITE memory access.
==5312==Hint: address points to the zero page.
#0 0x1020cde3f in main t.c:13
#1 0x108d414fd in start dyldMain.cpp:879

==5312==Register values:
rax = 0x  rbx = 0x7ff7bde35800  rcx = 0x7ff7bde357c0  
rdx = 0x1ffef7bc6af8  
rdi = 0x7ff7bde352f1  rsi = 0x  rbp = 0x7ff7bde358c0  
rsp = 0x7ff7bde357c0  
 r8 = 0x000102580480   r9 = 0x7ff7bde34a90  r10 = 0x  
r11 = 0x0206  
r12 = 0x000108db43a0  r13 = 0x7ff7bde35978  r14 = 0x0001020cdc80  
r15 = 0x000108da8010  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV t.c:13 in main
==5312==ABORTING
zsh: abort  ./a.out

Thanks,

Andrew Fish

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

[edk2-devel] [`edk2-devel][PATCH] Maintainers.txt: Add new reviewer for UefiPayloadPkg

2022-02-23 Thread Guo Dong

From: Guo Dong 

Add Sean Rhodes as UefiPayload reviewer mainly focus on
UEFI payload for coreboot support.

Signed-off-by: Guo Dong 
Cc: Ray Ni 
Cc: Benjamin You 
Cc: Maurice Ma 
Cc: Michael D Kinney 
---
 Maintainers.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 924069187e..d26f91c02e 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -601,6 +601,7 @@ M: Guo Dong  [gdong1]
 M: Ray Ni  [niruiyu]
 R: Maurice Ma  [mauricema]
 R: Benjamin You  [BenjaminYou]
+R: Sean Rhodes 
 S: Maintained
 
 UnitTestFrameworkPkg
-- 
2.35.1.windows.2



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

Re: [edk2-devel] [PATCH] UefiPayloadPkg: Add build option for Above 4G Memory

2022-02-23 Thread Guo Dong



Reviewed-by: Guo Dong 

-Original Message-
From: Sean Rhodes  
Sent: Wednesday, February 23, 2022 4:00 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Rhodes, Sean ; Ni, 
Ray ; Ma, Maurice ; You, Benjamin 

Subject: [PATCH] UefiPayloadPkg: Add build option for Above 4G Memory

When build option ABOVE_4G_MEMORY is set to true, nothing will change and EDKII 
will use all available memory.

Setting it to false will create memory type information HOB in payload entry, 
so that EDKII will reserve enough memory below 4G for EDKII modules. This 
option is useful for bootloaders that are not fully 64-bit aware such as Qubes 
R4.0.4 bootloader, Zorin and Proxmox.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Sean Rhodes 
---
 .../UefiPayloadEntry/UefiPayloadEntry.c   | 39 +++
 .../UefiPayloadEntry/UefiPayloadEntry.inf |  7 
 UefiPayloadPkg/UefiPayloadPkg.dec |  3 ++
 UefiPayloadPkg/UefiPayloadPkg.dsc |  3 ++
 4 files changed, 52 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 0fed1e3691..780348eadf 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -5,10 +5,44 @@
  **/ +#include  #include "UefiPayloadEntry.h"  
STATIC UINT32  mTopOfLowerUsableDram = 0; +EFI_MEMORY_TYPE_INFORMATION  
mDefaultMemoryTypeInformation[] = {+  { EfiACPIReclaimMemory,   FixedPcdGet32 
(PcdMemoryTypeEfiACPIReclaimMemory)   },+  { EfiACPIMemoryNVS,   
FixedPcdGet32 (PcdMemoryTypeEfiACPIMemoryNVS)   },+  { 
EfiReservedMemoryType,  FixedPcdGet32 (PcdMemoryTypeEfiReservedMemoryType)  },+ 
 { EfiRuntimeServicesData, FixedPcdGet32 (PcdMemoryTypeEfiRuntimeServicesData) 
},+  { EfiRuntimeServicesCode, FixedPcdGet32 
(PcdMemoryTypeEfiRuntimeServicesCode) },+  { EfiMaxMemoryType,   0  
 }+};++/**+   Function to reserve 
memory below 4GB for EDKII Modules.++   This causes the DXE to dispatch 
everything under 4GB and allows Operating+   System's that require 
EFI_LOADED_IMAGE to be under 4GB to start.+   e.g. Xen hypervisor used in 
Qubes.+**/+VOID+ForceModulesBelow4G (+  VOID+  )+{+  DEBUG ((DEBUG_INFO, 
"Building hob to restrict memory resorces to below 4G.\n"));++  //+  // Create 
Memory Type Information HOB+  //+  BuildGuidDataHob (+
,+mDefaultMemoryTypeInformation,+sizeof 
(mDefaultMemoryTypeInformation)+);+}+ /**Callback function to build 
resource descriptor HOB @@ -438,6 +472,11 @@ _ModuleEntryPoint (
   // Build other HOBs required by DXE   BuildGenericHob (); +  // Create a HOB 
to make resources for EDKII modules below 4G+  if (!FixedPcdGetBool 
(PcdDispatchModuleAbove4GMemory)) {+ForceModulesBelow4G ();+  }+   // Load 
the DXE Core   Status = LoadDxeCore ();   ASSERT_EFI_ERROR 
(Status);diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
index 1847d6481a..c4e4339ede 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
@@ -86,8 +86,15 @@
   gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemSize   
gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter   
gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES   
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
SOMETIMES_CONSUMES   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy
   ## SOMETIMES_CONSUMES +  
gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory+diff --git 
a/UefiPayloadPkg/UefiPayloadPkg.dec b/UefiPayloadPkg/UefiPayloadPkg.dec
index 551f0a4915..e9204d1168 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dec
+++ b/UefiPayloadPkg/UefiPayloadPkg.dec
@@ -83,6 +83,9 @@ 
gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x
  gUefiPayloadPkgTokenSpaceGuid.PcdPcdDriverFile|{ 0x57, 0x72, 0xcf, 0x80, 
0xab, 0x87, 0xf9, 0x47, 0xa3, 0xfe, 0xD5, 0x0B, 0x76, 0xd8, 0x95, 0x41 
}|VOID*|0x0018 +# Above 4G 
Memory+gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory|TRUE|BOOLEAN|0x0019+
 ## FFS filename to find the default variable initial data file. # @Prompt FFS 
Name of variable initial data file  
gUefiPayloadPkgTokenSpaceGuid.PcdNvsDataFile |{ 0x1a, 0xf1, 0xb1, 0xae, 0x42, 
0xcc, 0xcf, 0x4e, 0xac, 0x60, 0xdb, 0xab, 0xf6, 0xca, 0x69, 0xe6 
}|VOID*|0x0025diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc

[edk2-devel] [PATCH] UefiPayloadPkg: Add build option for Above 4G Memory

2022-02-23 Thread Sean Rhodes

When build option ABOVE_4G_MEMORY is set to true, nothing will change
and EDKII will use all available memory.

Setting it to false will create memory type information HOB in
payload entry, so that EDKII will reserve enough memory below 4G
for EDKII modules. This option is useful for bootloaders that are not
fully 64-bit aware such as Qubes R4.0.4 bootloader, Zorin and Proxmox.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Sean Rhodes 
---
 .../UefiPayloadEntry/UefiPayloadEntry.c   | 39 +++
 .../UefiPayloadEntry/UefiPayloadEntry.inf |  7 
 UefiPayloadPkg/UefiPayloadPkg.dec |  3 ++
 UefiPayloadPkg/UefiPayloadPkg.dsc |  3 ++
 4 files changed, 52 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 0fed1e3691..780348eadf 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -5,10 +5,44 @@
 
 **/
 
+#include 
 #include "UefiPayloadEntry.h"
 
 STATIC UINT32  mTopOfLowerUsableDram = 0;
 
+EFI_MEMORY_TYPE_INFORMATION  mDefaultMemoryTypeInformation[] = {
+  { EfiACPIReclaimMemory,   FixedPcdGet32 (PcdMemoryTypeEfiACPIReclaimMemory)  
 },
+  { EfiACPIMemoryNVS,   FixedPcdGet32 (PcdMemoryTypeEfiACPIMemoryNVS)  
 },
+  { EfiReservedMemoryType,  FixedPcdGet32 (PcdMemoryTypeEfiReservedMemoryType) 
 },
+  { EfiRuntimeServicesData, FixedPcdGet32 
(PcdMemoryTypeEfiRuntimeServicesData) },
+  { EfiRuntimeServicesCode, FixedPcdGet32 
(PcdMemoryTypeEfiRuntimeServicesCode) },
+  { EfiMaxMemoryType,   0  
 }
+};
+
+/**
+   Function to reserve memory below 4GB for EDKII Modules.
+
+   This causes the DXE to dispatch everything under 4GB and allows Operating
+   System's that require EFI_LOADED_IMAGE to be under 4GB to start.
+   e.g. Xen hypervisor used in Qubes.
+**/
+VOID
+ForceModulesBelow4G (
+  VOID
+  )
+{
+  DEBUG ((DEBUG_INFO, "Building hob to restrict memory resorces to below 
4G.\n"));
+
+  //
+  // Create Memory Type Information HOB
+  //
+  BuildGuidDataHob (
+,
+mDefaultMemoryTypeInformation,
+sizeof (mDefaultMemoryTypeInformation)
+);
+}
+
 /**
Callback function to build resource descriptor HOB
 
@@ -438,6 +472,11 @@ _ModuleEntryPoint (
   // Build other HOBs required by DXE
   BuildGenericHob ();
 
+  // Create a HOB to make resources for EDKII modules below 4G
+  if (!FixedPcdGetBool (PcdDispatchModuleAbove4GMemory)) {
+ForceModulesBelow4G ();
+  }
+
   // Load the DXE Core
   Status = LoadDxeCore ();
   ASSERT_EFI_ERROR (Status);
diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
index 1847d6481a..c4e4339ede 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
@@ -86,8 +86,15 @@
   gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemSize
   gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter
   gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize
+  gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS
+  gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
+  gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType
+  gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData
+  gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
SOMETIMES_CONSUMES
 
+  gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory
+
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec 
b/UefiPayloadPkg/UefiPayloadPkg.dec
index 551f0a4915..e9204d1168 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dec
+++ b/UefiPayloadPkg/UefiPayloadPkg.dec
@@ -83,6 +83,9 @@ 
gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x
 
 gUefiPayloadPkgTokenSpaceGuid.PcdPcdDriverFile|{ 0x57, 0x72, 0xcf, 0x80, 0xab, 
0x87, 0xf9, 0x47, 0xa3, 0xfe, 0xD5, 0x0B, 0x76, 0xd8, 0x95, 0x41 
}|VOID*|0x0018
 
+# Above 4G Memory
+gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory|TRUE|BOOLEAN|0x0019
+
 ## FFS filename to find the default variable initial data file.
 # @Prompt FFS Name of variable initial data file
  gUefiPayloadPkgTokenSpaceGuid.PcdNvsDataFile |{ 0x1a, 0xf1, 0xb1, 0xae, 0x42, 
0xcc, 0xcf, 0x4e, 0xac, 0x60, 0xdb, 0xab, 0xf6, 0xca, 0x69, 0xe6 
}|VOID*|0x0025
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 1ce96a51c1..4fe81a61d6 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -33,6 +33,7 @@
   DEFINE UNIVERSAL_PAYLOAD= FALSE
   DEFINE SECURITY_STUB_ENABLE = TRUE

Re: [edk2-devel] [PATCH] BlSupportSmm: fix definition of SetSmrr()

2022-02-23 Thread Guo Dong



Reviewed-by: Guo Dong 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Sean Rhodes
Sent: Wednesday, February 23, 2022 3:55 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Rhodes, Sean ; Ni, 
Ray ; Ma, Maurice ; You, Benjamin 
; Matt DeVillier 
Subject: [edk2-devel] [PATCH] BlSupportSmm: fix definition of SetSmrr()

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Matt DeVillier 
Signed-off-by: Sean Rhodes 
---
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
index dcc4d60bb2..0d16aec8ef 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
@@ -191,6 +191,7 @@ SmmFeatureLockOnS3 (
   @param[in] ProcedureArgument  Pointer to SMRR_BASE_MASK structure. **/ 
VOID+EFIAPI SetSmrr (   IN VOID  *ProcedureArgument   )-- 
2.32.0



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86928): https://edk2.groups.io/g/devel/message/86928
Mute This Topic: https://groups.io/mt/89277119/1781375
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [guo.d...@intel.com] 
-=-=-=-=-=-=




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

[edk2-devel] [PATCH] BlSupportSmm: fix definition of SetSmrr()

2022-02-23 Thread Sean Rhodes

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Matt DeVillier 
Signed-off-by: Sean Rhodes 
---
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
index dcc4d60bb2..0d16aec8ef 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
@@ -191,6 +191,7 @@ SmmFeatureLockOnS3 (
   @param[in] ProcedureArgument  Pointer to SMRR_BASE_MASK structure.
 **/
 VOID
+EFIAPI
 SetSmrr (
   IN VOID  *ProcedureArgument
   )
-- 
2.32.0



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

Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

2022-02-23 Thread Ard Biesheuvel

On Wed, 23 Feb 2022 at 19:14, Ashish Singhal  wrote:
>
> Ard,
>
> During PrePi, I setup the initial memory map by calling into ArmConfigureMmu 
> function with my memory table where device memory regions have attribute of 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE and DRAM regions have attribute of 
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK.
>
> For device memory, XN bit is set by ArmMemoryAttributeToPageAttribute 
> function. After PrePi, when I add a region of memory to device memory from a 
> DXE driver, I call gDS->AddMemorySpace with EfiGcdMemoryTypeMemoryMappedIo 
> and EFI_MEMORY_UC | EFI_MEMORY_RUNTIME followed by 
> gDS->SetMemorySpaceAttributes with EFI_MEMORY_UC.
>
> Please let me know in case I have still not understood your question.
>

This all looks ok. But the real question is whether the address that
the speculative access targets is mapped using the XN attribute or
not, so you will need to find a way to check that.

So there are a couple of options:
- The XN attribute is set correctly, but the CPU is speculatively
fetching instructions anyway. This would imply a severe hardware bug,
and flushing the I-cache is unlikely to make a difference.
- The speculative access is not the result of an instruction fetch, in
which case I-cache maintenance is unlikely to help either.
- The XN bit is not being set correctly, and so the MMU code needs to be fixed.

Papering over this by adding I-cache maintenance doesn't seem the best
course of action tbh.

-- 
Ard.


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

Re: [edk2-devel] [PATCH] BlSupportSmm: fix definition of SetSmrr()

2022-02-23 Thread Guo Dong



The change looks good.
Please not update submodule 
MdeModulePkg/Library/BrotliCustomDecompressLib/brotli

Thanks,
Guo

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Sean Rhodes
Sent: Sunday, February 20, 2022 11:15 AM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Matt DeVillier ; 
Ni, Ray ; Ma, Maurice ; You, Benjamin 

Subject: [edk2-devel] [PATCH] BlSupportSmm: fix definition of SetSmrr()

From: Matt DeVillier 

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Matt DeVillier 
Change-Id: Id5b077ad6c79717a9d97d4228145791ef062962c
---
 MdeModulePkg/Library/BrotliCustomDecompressLib/brotli | 2 +-
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli 
b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
index f4153a09f8..666c3280cc 16
--- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
+++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
@@ -1 +1 @@
-Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
+Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d
diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
index dcc4d60bb2..0d16aec8ef 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
@@ -191,6 +191,7 @@ SmmFeatureLockOnS3 (
   @param[in] ProcedureArgument  Pointer to SMRR_BASE_MASK structure. **/ 
VOID+EFIAPI SetSmrr (   IN VOID  *ProcedureArgument   )-- 
2.32.0



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86815): https://edk2.groups.io/g/devel/message/86815
Mute This Topic: https://groups.io/mt/89277119/1781375
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [guo.d...@intel.com] 
-=-=-=-=-=-=




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

Re: [edk2-devel] [PATCH] UefiPayloadPkg: Add build option for Above 4G Memory

2022-02-23 Thread Guo Dong



+# Above 4G Memory
+gUefiPayloadPkgTokenSpaceGuid.PcdAbove4GMemory|TRUE|BOOLEAN|0x0019

It is not clear for the usage from the PCD name and comments.
Better to change PcdAbove4GMemory to PcdDispatchModuleAbove4GMemory or others?

Thanks,
Guo

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Sean Rhodes
Sent: Sunday, February 20, 2022 2:41 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Rhodes, Sean ; Ni, 
Ray ; Ma, Maurice ; You, Benjamin 

Subject: [edk2-devel] [PATCH] UefiPayloadPkg: Add build option for Above 4G 
Memory

When build option ABOVE_4G_MEMORY is set to true, nothing will change and EDKII 
will use all available memory.

Setting it to false will create memory type information HOB in payload entry, 
so that EDKII will reserve enough memory below 4G for EDKII modules. This 
option is useful for bootloaders that are not fully 64-bit aware such as Qubes 
R4.0.4 bootloader, Zorin and Proxmox.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Sean Rhodes 
---
 .../Library/BrotliCustomDecompressLib/brotli  |  2 +-
 .../UefiPayloadEntry/UefiPayloadEntry.c   | 39 +++
 .../UefiPayloadEntry/UefiPayloadEntry.inf |  7 
 UefiPayloadPkg/UefiPayloadPkg.dec |  3 ++
 UefiPayloadPkg/UefiPayloadPkg.dsc |  3 ++
 5 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli 
b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
index f4153a09f8..666c3280cc 16
--- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
+++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
@@ -1 +1 @@
-Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
+Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d
diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 0fed1e3691..998895e201 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -5,10 +5,44 @@
  **/ +#include  #include "UefiPayloadEntry.h"  
STATIC UINT32  mTopOfLowerUsableDram = 0; +EFI_MEMORY_TYPE_INFORMATION  
mDefaultMemoryTypeInformation[] = {+  { EfiACPIReclaimMemory,   FixedPcdGet32 
(PcdMemoryTypeEfiACPIReclaimMemory)   },+  { EfiACPIMemoryNVS,   
FixedPcdGet32 (PcdMemoryTypeEfiACPIMemoryNVS)   },+  { 
EfiReservedMemoryType,  FixedPcdGet32 (PcdMemoryTypeEfiReservedMemoryType)  },+ 
 { EfiRuntimeServicesData, FixedPcdGet32 (PcdMemoryTypeEfiRuntimeServicesData) 
},+  { EfiRuntimeServicesCode, FixedPcdGet32 
(PcdMemoryTypeEfiRuntimeServicesCode) },+  { EfiMaxMemoryType,   0  
 }+};++/**+   Function to reserve 
memory below 4GB for EDKII Modules.++   This causes the DXE to dispatch 
everything under 4GB and allows Operating+   System's that require 
EFI_LOADED_IMAGE to be under 4GB to start.+   e.g. Xen hypervisor used in 
Qubes.+**/+VOID+ForceModulesBelow4G (+  VOID+  )+{+  DEBUG ((DEBUG_INFO, 
"Building hob to restrict memory resorces to below 4G.\n"));++  //+  // Create 
Memory Type Information HOB+  //+  BuildGuidDataHob (+
,+mDefaultMemoryTypeInformation,+sizeof 
(mDefaultMemoryTypeInformation)+);+}+ /**Callback function to build 
resource descriptor HOB @@ -438,6 +472,11 @@ _ModuleEntryPoint (
   // Build other HOBs required by DXE   BuildGenericHob (); +  // Create a HOB 
to make resources for EDKII modules below 4G+  if (!FixedPcdGetBool 
(PcdAbove4GMemory)) {+ForceModulesBelow4G ();+  }+   // Load the DXE Core   
Status = LoadDxeCore ();   ASSERT_EFI_ERROR (Status);diff 
--git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
index 1847d6481a..2ca47e3bb5 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
@@ -86,8 +86,15 @@
   gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemSize   
gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter   
gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData+  
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES   
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
SOMETIMES_CONSUMES   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy
   ## SOMETIMES_CONSUMES +  gUefiPayloadPkgTokenSpaceGuid.PcdAbove4GMemory+diff 
--git a/UefiPayloadPkg/UefiPayloadPkg.dec b/UefiPayloadPkg/UefiPayloadPkg.dec
index 551f0a4915..653a52b5a7 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dec
+++ b/UefiPayloadPkg/UefiPayloadPkg.dec
@@ -83,6

[edk2-devel] [PATCH 1/2] SecurityPkg: Add RNG support

2022-02-23 Thread Sean Rhodes

From: Patrick Rudolph 

Uses the RDRAND instruction if available and install EfiRngProtocol.
The protocol may be used by iPXE or the Linux kernel to gather entropy.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Guo Dong 
Signed-off-by: Patrick Rudolph 
---
 SecurityPkg/Library/BaseRngLib/BaseRng.c  | 199 ++
 SecurityPkg/Library/BaseRngLib/BaseRngLib.inf |  32 +++
 SecurityPkg/Library/BaseRngLib/BaseRngLib.uni |  17 ++
 3 files changed, 248 insertions(+)
 create mode 100644 SecurityPkg/Library/BaseRngLib/BaseRng.c
 create mode 100644 SecurityPkg/Library/BaseRngLib/BaseRngLib.inf
 create mode 100644 SecurityPkg/Library/BaseRngLib/BaseRngLib.uni

diff --git a/SecurityPkg/Library/BaseRngLib/BaseRng.c 
b/SecurityPkg/Library/BaseRngLib/BaseRng.c
new file mode 100644
index 00..c21e713cb0
--- /dev/null
+++ b/SecurityPkg/Library/BaseRngLib/BaseRng.c
@@ -0,0 +1,199 @@
+/** @file
+  Random number generator services that uses RdRand instruction access
+  to provide high-quality random numbers.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+
+STATIC BOOLEAN  mHasRdRand;
+
+//
+// Bit mask used to determine if RdRand instruction is supported.
+//
+#define RDRAND_MASK  BIT30
+
+//
+// Limited retry number when valid random data is returned.
+// Uses the recommended value defined in Section 7.3.17 of "Intel 64 and IA-32
+// Architectures Software Developer's Mannual".
+//
+#define RDRAND_RETRY_LIMIT  10
+
+/**
+  The constructor function checks whether or not RDRAND instruction is 
supported
+  by the host hardware.
+
+  The constructor function checks whether or not RDRAND instruction is 
supported.
+  It will always return RETURN_SUCCESS.
+
+  @retval RETURN_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+RETURN_STATUS
+EFIAPI
+BaseRngLibConstructor (
+  VOID
+  )
+{
+  UINT32  RegEax;
+  UINT32  RegEcx;
+
+  AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
+  if (RegEax < 1) {
+mHasRdRand = FALSE;
+return RETURN_SUCCESS;
+  }
+
+  //
+  // Determine RDRAND support by examining bit 30 of the ECX register returned 
by
+  // CPUID. A value of 1 indicates that processor support RDRAND instruction.
+  //
+  AsmCpuid (CPUID_VERSION_INFO, 0, 0, , 0);
+
+  mHasRdRand = ((RegEcx & RDRAND_MASK) == RDRAND_MASK);
+
+  return RETURN_SUCCESS;
+}
+
+/**
+  Generates a 16-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 16-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber16 (
+  OUT UINT16  *Rand
+  )
+{
+  UINT32  Index;
+
+  ASSERT (Rand != NULL);
+
+  if (mHasRdRand) {
+//
+// A loop to fetch a 16 bit random value with a retry count limit.
+//
+for (Index = 0; Index < RDRAND_RETRY_LIMIT; Index++) {
+  if (AsmRdRand16 (Rand)) {
+return TRUE;
+  }
+}
+  }
+
+  return FALSE;
+}
+
+/**
+  Generates a 32-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 32-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber32 (
+  OUT UINT32  *Rand
+  )
+{
+  UINT32  Index;
+
+  ASSERT (Rand != NULL);
+
+  if (mHasRdRand) {
+//
+// A loop to fetch a 32 bit random value with a retry count limit.
+//
+for (Index = 0; Index < RDRAND_RETRY_LIMIT; Index++) {
+  if (AsmRdRand32 (Rand)) {
+return TRUE;
+  }
+}
+  }
+
+  return FALSE;
+}
+
+/**
+  Generates a 64-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 64-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber64 (
+  OUT UINT64  *Rand
+  )
+{
+  UINT32  Index;
+
+  ASSERT (Rand != NULL);
+
+  if (mHasRdRand) {
+//
+// A loop to fetch a 64 bit random value with a retry count limit.
+//
+for (Index = 0; Index < RDRAND_RETRY_LIMIT; Index++) {
+  if (AsmRdRand64 (Rand)) {
+return TRUE;
+  }
+}
+  }
+
+  return FALSE;
+}
+
+/**
+  Generates a 128-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 128-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber128 (
+  OUT UINT64  *Rand
+  )
+{
+  ASSERT (Rand != NULL);
+
+  //
+  // Read first 64 bits
+  //
+  if (!GetRandomNumber64 (Rand)) {
+return FALSE;
+  }
+
+  //
+  // Read second 64 bits
+  //
+  return GetRandomNumber64 (++Rand);
+}

[edk2-devel] [PATCH 2/2] UefiPayloadPkg: Hook up RNG support

2022-02-23 Thread Sean Rhodes

From: Patrick Rudolph 

Hoop Up RNG from SecurityPkg.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Patrick Rudolph 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 8 
 UefiPayloadPkg/UefiPayloadPkg.fdf | 4 
 2 files changed, 12 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 1ce96a51c1..0d4b4da24f 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -703,6 +703,14 @@
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
 !endif
 
+  #
+  # Random Number Generator
+  #
+  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf {
+  
+  RngLib|SecurityPkg/Library/BaseRngLib/BaseRngLib.inf
+  }
+
   #--
   #  Build the shell
   #--
diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf 
b/UefiPayloadPkg/UefiPayloadPkg.fdf
index c7b04978ad..6af1a8c8aa 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -229,6 +229,10 @@ INF MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
 #
 INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 
+# Random Number Generator
+#
+INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
+
 #
 # UEFI network modules
 #
-- 
2.32.0



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

Re: [edk2-devel] [PATCH v3 1/1] UefiPayloadPkg/PayloadLoaderPeim: Use INT64 as input parameter

2022-02-23 Thread Guo Dong



Reviewed-by: Guo Dong 

-Original Message-
From: Jiang, Guomin  
Sent: Sunday, February 20, 2022 11:44 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Ma, Maurice 
; You, Benjamin 
Subject: [PATCH v3 1/1] UefiPayloadPkg/PayloadLoaderPeim: Use INT64 as input 
parameter

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

It will have some potential issue when memory larger than 2G because the high 
memory address will be fill with 0x when do the operation of INTN + 
INT64 but it is 32 bit normal data in fact.

Should use same data type INT64 + INT64.

V3:
1. Use INT64 as input parameter because all date type is 64 bit
V2:
1. Force the data type to UINTN to avoid high dword be filled with 0x 
2. Keep INTN because the offset may postive or negative.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Signed-off-by: Guomin Jiang 
---
 UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c 
b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c
index dc47a05c6e4a..c8dbb887340b 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c
+++ b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c
@@ -108,7 +108,7 @@ ProcessRelocation64 (
   IN  UINT64  RelaSize,
   IN  UINT64  RelaEntrySize,
   IN  UINT64  RelaType,
-  IN  INTNDelta,
+  IN  INT64   Delta,
   IN  BOOLEAN DynamicLinking
   )
 {
--
2.35.1.windows.2



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

Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

2022-02-23 Thread Ashish Singhal via groups.io

Ard,

During PrePi, I setup the initial memory map by calling into ArmConfigureMmu 
function with my memory table where device memory regions have attribute of 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE and DRAM regions have attribute of 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK.

For device memory, XN bit is set by ArmMemoryAttributeToPageAttribute function. 
After PrePi, when I add a region of memory to device memory from a DXE driver, 
I call gDS->AddMemorySpace with EfiGcdMemoryTypeMemoryMappedIo and 
EFI_MEMORY_UC | EFI_MEMORY_RUNTIME followed by gDS->SetMemorySpaceAttributes 
with EFI_MEMORY_UC.

Please let me know in case I have still not understood your question.

In our case, UEFI is running in NS-EL2. I understand what I am proposing may 
not be a proper fix. I am looking for help on what could be a fix for this as 
we are using all upstream code for memory management.

Thanks
Ashish

From: Ard Biesheuvel 
Sent: Wednesday, February 23, 2022 10:40 AM
To: edk2-devel-groups-io ; Ashish Singhal 

Cc: Marc Zyngier ; Sami Mujawar ; Ard 
Biesheuvel ; Leif Lindholm 

Subject: Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU 
Enable

External email: Use caution opening links or attachments

On Wed, 23 Feb 2022 at 18:36, Ashish Singhal via groups.io
 wrote:
>
> Hello Ard and Marc,
>
> I apologize for not providing the background on this in the commit message 
> and I understand the commit message is not very clear as well. Let me try to 
> summarize the problem.
>
> In our UEFI implementation, we are doing the following as part of the initial 
> MMU setup:
>
> Set the applicable device memory as nGnRnE memory.
> Set the whole DRAM as normal memory that translates to RW and executable 
> memory.
> Enable caches and MMU.
> At this time, the memory map looks correct when I check that from DS-5.
>

I have asked you a number of times about the XN attribute. How and
where are you setting it for the device regions?

> When we start dispatching drivers, DxeCore dispatches a driver and marks its 
> code area as RO and executable and its data region as RW and non-executable. 
> What we are seeing randomly is that some of the page tables (using DS-5) have 
> invalid output address that leads to the correct input address from UEFI 
> being translated to an unavailable memory location causing a crash sometime 
> in EL2 or sometimes as a RAS error in EL3.
>

At which EL does UEFI run? If at EL1, is it running under a stage2
mapping? If so, does the stage 2 mapping set the XN attribute
appropriately for the device mappings?

> When I reached out to the CPU team here, they said Arm® Cortex®-A78AE is a 
> highly speculative core and we need to have appropriate barriers in place so 
> that there is consistency in the way an address is accessed especially if it 
> is done right after there is a change in translation tables. Based on this, I 
> started some experimentation wrt caches whenever MMUs are enabled and I found 
> that invalidating the instruction cache after enabling MMUs solves this 
> problem.
>

It may hide it, but I don't think it is a proper fix.

> Please note that I could be wrong with my hypothesis here and I may just be 
> masking the issue. If that is the case, please let me know what I should be 
> trying as I am out of ideas at this point. Also, the same UEFI works on 
> NVIDIA's Xavier Silicon that has Carmel cores but shows this issue on Orin 
> Silicon that has Arm® Cortex®-A78AE v8.2 64-bit CPU.
>

Thanks,
Ard.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86921): https://edk2.groups.io/g/devel/message/86921
Mute This Topic: https://groups.io/mt/89309504/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] .pytool/Plugin/UncrustifyCheck: Output file diffs by default

2022-02-23 Thread Rebecca Cran

This doesn't appear to work. If I change 
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c to introduce an error, 
then I get the following output (with verbose mode):



INFO - 
INFO - --Cmd Output Finished---
INFO - - Running Time (mm:ss): 00:07 --
INFO - --- Return Code: 0x 
INFO - 
INFO - Uncrustify executed against 1035 files in MdeModulePkg in 7.67 
seconds.


INFO - Calculating file diffs. This might take a while...
ERROR - .../edk2/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
ERROR - --->Test Failed: Uncrustify Coding Standard Test NO-TARGET 
returned 1

PROGRESS - --Running MdeModulePkg: Spell Check Test NO-TARGET --

So it's seeing that _output_file_diffs is True, but it appears that 
there aren't any formatted_files?



--
Rebecca Cran


On 2/10/22 09:19, Michael Kubacki wrote:

From: Michael Kubacki

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

Changes the default for the "OutputFileDiffs" configuration option
to "True" so the formatting suggestions detected by Uncrustify
will be output in the test case log. The diff is printed in unified
diff format.

This was disabled by default during the initial enabling of
Uncrustify to reduce overall execution time of the plugin against
the codebase due to the large number of changes detected.

Cc: Michael D Kinney
Cc: Liming Gao
Cc: Sean Brogan
Cc: Bret Barkelew
Signed-off-by: Michael Kubacki
---
  .pytool/Plugin/UncrustifyCheck/Readme.md  | 4 ++--
  .pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py | 6 +++---
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/.pytool/Plugin/UncrustifyCheck/Readme.md 
b/.pytool/Plugin/UncrustifyCheck/Readme.md
index bb263bcc87d7..0c46fd241a7a 100644
--- a/.pytool/Plugin/UncrustifyCheck/Readme.md
+++ b/.pytool/Plugin/UncrustifyCheck/Readme.md
@@ -42,7 +42,7 @@ The plugin can be configured with a few optional 
configuration options.
"AuditOnly": False,   # Don't fail the build if there are 
errors.  Just log them.
"ConfigFilePath": "", # Custom path to an Uncrustify config 
file.
"IgnoreStandardPaths": [],# Standard Plugin defined paths that 
should be ignored.
-  "OutputFileDiffs": False, # Output chunks of formatting diffs in the 
test case log.
+  "OutputFileDiffs": True,  # Output chunks of formatting diffs in the 
test case log.
  # This can significantly slow down the 
plugin on very large packages.
"SkipGitExclusions": False# Don't exclude git ignored files and 
files in git submodules.
}
@@ -82,7 +82,7 @@ to be ignored.
  
  ### `OutputFileDiffs`
  
-`Boolean` - Default is `False`.

+`Boolean` - Default is `True`.
  
  If `True`, output diffs of formatting changes into the test case log. This is helpful to exactly understand what changes

  need to be made to the source code in order to fix a coding standard 
compliance issue.
diff --git a/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py 
b/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
index 6db8d1739a80..ea8396942b16 100644
--- a/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
+++ b/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
@@ -494,13 +494,13 @@ class UncrustifyCheck(ICiBuildPlugin):
  Initializes options that influence test case output.
  """
  self._audit_only_mode = False
-self._output_file_diffs = False
+self._output_file_diffs = True
  
  if "AuditOnly" in self._package_config and self._package_config["AuditOnly"]:

  self._audit_only_mode = True
  
-if "OutputFileDiffs" in self._package_config and self._package_config["OutputFileDiffs"]:

-self._output_file_diffs = True
+if "OutputFileDiffs" in self._package_config and not 
self._package_config["OutputFileDiffs"]:
+self._output_file_diffs = False
  
  def _log_uncrustify_app_info(self) -> None:

  """



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

Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

2022-02-23 Thread Ard Biesheuvel

On Wed, 23 Feb 2022 at 18:36, Ashish Singhal via groups.io
 wrote:
>
> Hello Ard and Marc,
>
> I apologize for not providing the background on this in the commit message 
> and I understand the commit message is not very clear as well. Let me try to 
> summarize the problem.
>
> In our UEFI implementation, we are doing the following as part of the initial 
> MMU setup:
>
> Set the applicable device memory as nGnRnE memory.
> Set the whole DRAM as normal memory that translates to RW and executable 
> memory.
> Enable caches and MMU.
> At this time, the memory map looks correct when I check that from DS-5.
>

I have asked you a number of times about the XN attribute. How and
where are you setting it for the device regions?

> When we start dispatching drivers, DxeCore dispatches a driver and marks its 
> code area as RO and executable and its data region as RW and non-executable. 
> What we are seeing randomly is that some of the page tables (using DS-5) have 
> invalid output address that leads to the correct input address from UEFI 
> being translated to an unavailable memory location causing a crash sometime 
> in EL2 or sometimes as a RAS error in EL3.
>

At which EL does UEFI run? If at EL1, is it running under a stage2
mapping? If so, does the stage 2 mapping set the XN attribute
appropriately for the device mappings?


> When I reached out to the CPU team here, they said Arm® Cortex®-A78AE is a 
> highly speculative core and we need to have appropriate barriers in place so 
> that there is consistency in the way an address is accessed especially if it 
> is done right after there is a change in translation tables. Based on this, I 
> started some experimentation wrt caches whenever MMUs are enabled and I found 
> that invalidating the instruction cache after enabling MMUs solves this 
> problem.
>

It may hide it, but I don't think it is a proper fix.

> Please note that I could be wrong with my hypothesis here and I may just be 
> masking the issue. If that is the case, please let me know what I should be 
> trying as I am out of ideas at this point. Also, the same UEFI works on 
> NVIDIA's Xavier Silicon that has Carmel cores but shows this issue on Orin 
> Silicon that has Arm® Cortex®-A78AE v8.2 64-bit CPU.
>

Thanks,
Ard.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86919): https://edk2.groups.io/g/devel/message/86919
Mute This Topic: https://groups.io/mt/89309504/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] OvmfPkg: Generate CloudHv as a PVH ELF binary

2022-02-23 Thread Boeuf, Sebastien

On Wed, 2022-02-23 at 13:35 +0100, Sebastien Boeuf wrote:
> On Wed, 2022-02-23 at 12:22 +0100, Gerd Hoffmann wrote:
> > On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> > > From: Sebastien Boeuf 
> > > 
> > > Following the model from the Xen target, CloudHv is generated as
> > > a
> > > PVH
> > > ELF binary to take advantage of the PVH specification.
> > 
> > > --- /dev/null
> > > +++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> > 
> > Why create a new copy of this?  What are the differences to the Xen
> > version?  I guess they are small so we can maybe have a common
> > ElfPvhHeaderGenerator.c with command line switches?
> 
> That's right, I can work on updating the generator to take some
> parameters so that I won't need the duplication of the file.

This has been fixed part of v2 patchset.

> 
> > 
> > > -  OvmfPkg/ResetVector/ResetVector.inf
> > > +  OvmfPkg/XenResetVector/XenResetVector.inf
> > 
> > Why this is needed?
> 
> It stores the "Start of day" structure pointer, which is then used by
> some follow up patches to access hvm_start_info structure (containing
> the PVH boot information).
> 
> > 
> > > +DATA = {
> > > +  #
> > > +  # This hex array have been generated by
> > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > +  # and copied manually.
> > 
> > How about having the generator write a .fdf.inc file which you can
> > just
> > include directly without manual copying?
> 
> I understand the idea, but do you have any pointer to some existing
> code in the repo already doing such thing?
> 
> Thanks,
> Sebastien
> 
> > 
> > take care,
> >   Gerd
> > 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

Re: [edk2-devel] [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

2022-02-23 Thread Ashish Singhal via groups.io

Hello Ard and Marc,

I apologize for not providing the background on this in the commit message and 
I understand the commit message is not very clear as well. Let me try to 
summarize the problem.

In our UEFI implementation, we are doing the following as part of the initial 
MMU setup:

  1.  Set the applicable device memory as nGnRnE memory.
  2.  Set the whole DRAM as normal memory that translates to RW and executable 
memory.
  3.  Enable caches and MMU.
  4.  At this time, the memory map looks correct when I check that from DS-5.

When we start dispatching drivers, DxeCore dispatches a driver and marks its 
code area as RO and executable and its data region as RW and non-executable. 
What we are seeing randomly is that some of the page tables (using DS-5) have 
invalid output address that leads to the correct input address from UEFI being 
translated to an unavailable memory location causing a crash sometime in EL2 or 
sometimes as a RAS error in EL3.

When I reached out to the CPU team here, they said Arm® Cortex®-A78AE is a 
highly speculative core and we need to have appropriate barriers in place so 
that there is consistency in the way an address is accessed especially if it is 
done right after there is a change in translation tables. Based on this, I 
started some experimentation wrt caches whenever MMUs are enabled and I found 
that invalidating the instruction cache after enabling MMUs solves this problem.

Please note that I could be wrong with my hypothesis here and I may just be 
masking the issue. If that is the case, please let me know what I should be 
trying as I am out of ideas at this point. Also, the same UEFI works on 
NVIDIA's Xavier Silicon that has Carmel cores but shows this issue on Orin 
Silicon that has Arm® Cortex®-A78AE v8.2 64-bit CPU.

@Marc Zyngier,

I agree with your concern about using "dsb sy" and we should replace that with 
"dsb nsh" as we are running this only on a single core during boot.

Thanks
Ashish

From: Marc Zyngier 
Sent: Wednesday, February 23, 2022 1:58 AM
To: Ard Biesheuvel ; Ashish Singhal 
Cc: edk2-devel-groups-io ; Sami Mujawar 
; Ard Biesheuvel ; Leif 
Lindholm 
Subject: Re: [PATCH] ArmPkg: Invalidate Instruction Cache On MMU Enable

External email: Use caution opening links or attachments

On Wed, 23 Feb 2022 07:02:28 +,
Ard Biesheuvel  wrote:
>
> (+ Marc)
>
> On Tue, 22 Feb 2022 at 03:42, Ashish Singhal  wrote:
> >
> > Even with MMU turned off, instruction cache can speculate
> > and fetch instructions. This can cause a crash if region
> > being executed has been modified recently. With this patch,
> > we ensure that instruction cache is invalidated right after
> > MMU has been enabled and any potentially stale instruction
> > fetched earlier has been discarded.

Are you doing code patching while the MMU is off?

> >
>
> I don't follow this reasoning. Every time the UEFI image loader loads
> an image into memory, it does so with MMU and caches enabled, and the
> code regions are cleaned to the PoU before being invalidated in the
> I-cache. So how could these regions be stale? The only code that needs
> special care here is the little trampoline that executes with the MMU
> off, but this is being taken care of explicitly, by cleaning the code
> to the PoC before invoking it.
>
> > This is specially helpful when the memory attributes of a
> > region in MMU are being changed and some instructions
> > operating on the region are prefetched in the instruction
> > cache.
> >

Huh, this is way too vague. How do you expect anyone to understand
your problem based on this?

>
> This sounds like a TLB problem not a cache problem. For the sake of
> posterity, could you include a more detailed description of the issue
> in the commit log? IIRC, this is about speculative instruction fetches
> hitting device memory locations?
>
> As I mentioned before, the architecture does not permit speculative
> instruction fetches for regions mapped with the XN attribute.
>
> Is the issue occurring under virtualization? Is there a stage 2
> mapping that lacks the XN attribute for the device memory region in
> question?
>
> > Signed-off-by: Ashish Singhal 
> > ---
> >  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S   | 4 +++-
> >  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 2 ++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> > b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> > index d3cc1e8671..9648245182 100644
> > --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> > +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> > @@ -89,7 +89,9 @@ ASM_FUNC(ArmEnableMmu)
> > dsb nsh
> > isb
> > msr sctlr_el3, x0   // Write back
> > -4: isb
> > +4: ic  iallu
> > +   dsb sy

Why DSB SY? Given that you are only invalidating on a single CPU,
DSB NSH should be enough.

> > +   isb
> >

[edk2-devel] [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary

2022-02-23 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/CloudHv/CloudHvX64.dsc |  2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf | 94 +-
 2 files changed, 93 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 3172100310..b4d855d80f 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -631,7 +631,7 @@
 #
 

 [Components]
-  OvmfPkg/ResetVector/ResetVector.inf
+  OvmfPkg/XenResetVector/XenResetVector.inf
 
   #
   # SEC Phase modules
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index ce3302c6d6..8eebcf 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -24,7 +24,97 @@ ErasePolarity = 1
 BlockSize = $(BLOCK_SIZE)
 NumBlocks = $(FW_BLOCKS)
 
-!include OvmfPkg/VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x|0xe000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x|0x0004
+!endif
+DATA = {
+  #
+  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
+  # and copied manually.
+  # Built with "gcc -D PVH64 -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c"
+  # and run with "./elf_gen 4194304".
+  #
+  # ELF file header
+  0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00,
+  0xd0, 0xff, 0x4f, 0x00, 0x00, 0x00, 0x00, 0x00,  # hdr.e_entry
+  0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x38, 0x00, 0x02, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+
+  # ELF Program segment headers
+  # - Load segment
+  0x01, 0x00, 0x00, 0x00,
+  0x07, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x40, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x40, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  # - ELFNOTE segment
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x14, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x14, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+
+  # XEN_ELFNOTE_PHYS32_ENTRY
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x12, 0x00, 0x00, 0x00,
+  0x58, 0x65, 0x6e, 0x00,
+  0xd0, 0xff, 0x4f, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0xe000|0x1000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x0004|0x1000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0xf000|0x1000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x1000
+!endif
+#NV_FTW_WORKING
+DATA = {
+  # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = 
gEdkiiWorkingBlockSignatureGuid =
+  #  { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 
0x95 }}
+  0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+  0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95,
+  # Crc:UINT32#WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+  0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+  # WriteQueueSize: UINT64
+  0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0001|0x0001
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
 
 $(VARS_SIZE)|$(FVMAIN_SIZE)
 FV = FVMAIN_COMPACT
@@ -142,7 +232,7 @@ READ_LOCK_STATUS   = TRUE
 #
 INF  OvmfPkg/Sec/SecMain.inf
 
-INF  RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+INF  RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
 
 

 [FV.PEIFV]
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



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

[edk2-devel] [PATCH v2 4/5] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS

2022-02-23 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/PlatformPei/MemDetect.c | 73 +
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 +
 2 files changed, 75 insertions(+)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 1bcb5a08bc..8ecc8257f9 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -17,6 +17,7 @@ Module Name:
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -315,6 +316,73 @@ ScanOrAdd64BitE820Ram (
   return EFI_SUCCESS;
 }
 
+/**
+  Returns PVH memmap
+
+  @param Entries  Pointer to PVH memmap
+  @param CountNumber of entries
+
+  @return EFI_STATUS
+**/
+EFI_STATUS
+GetPvhMemmapEntries (
+  struct hvm_memmap_table_entry  **Entries,
+  UINT32 *Count
+  )
+{
+  UINT32 *PVHResetVectorData;
+  struct hvm_start_info  *pvh_start_info;
+
+  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+  if (PVHResetVectorData == 0) {
+return EFI_NOT_FOUND;
+  }
+
+  pvh_start_info = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];
+
+  *Entries = (struct hvm_memmap_table_entry 
*)(UINTN)pvh_start_info->memmap_paddr;
+  *Count   = pvh_start_info->memmap_entries;
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+UINT64
+GetHighestSystemMemoryAddressFromPvhMemmap (
+  BOOLEAN  Below4gb
+  )
+{
+  struct hvm_memmap_table_entry  *Memmap;
+  UINT32 MemmapEntriesCount;
+  struct hvm_memmap_table_entry  *Entry;
+  EFI_STATUS Status;
+  UINT32 Loop;
+  UINT64 HighestAddress;
+  UINT64 EntryEnd;
+
+  HighestAddress = 0;
+
+  Status = GetPvhMemmapEntries (, );
+  ASSERT_EFI_ERROR (Status);
+
+  for (Loop = 0; Loop < MemmapEntriesCount; Loop++) {
+Entry= Memmap + Loop;
+EntryEnd = Entry->addr + Entry->size;
+
+if ((Entry->type == XEN_HVM_MEMMAP_TYPE_RAM) &&
+(EntryEnd > HighestAddress))
+{
+  if (Below4gb && (EntryEnd <= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  }
+}
+  }
+
+  return HighestAddress;
+}
+
 UINT32
 GetSystemMemorySizeBelow4gb (
   VOID
@@ -325,6 +393,11 @@ GetSystemMemorySizeBelow4gb (
   UINT8   Cmos0x34;
   UINT8   Cmos0x35;
 
+  if (mHostBridgeDevId == CLOUDHV_DEVICE_ID) {
+// Get the information from PVH memmap
+return (UINT32)GetHighestSystemMemoryAddressFromPvhMemmap (TRUE);
+  }
+
   Status = ScanOrAdd64BitE820Ram (FALSE, , NULL);
   if ((Status == EFI_SUCCESS) && (LowerMemorySize > 0)) {
 return (UINT32)LowerMemorySize;
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 8ef404168c..212aa7b047 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -91,6 +91,8 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Boeuf, Sebastien

On Wed, 2022-02-23 at 14:14 +, Yao, Jiewen wrote:
> Yes, justification in bugzilla and README, please.

I've just submitted a v2 patchset including the README, let me know
what you think about it.

I'm still waiting for my Bugzilla account to be created.

> 
> I suggestion you send a different email to ask the different topic -
> not distract people.

Sorry, I'll send a separate email.

Thanks,
Sebastien
> 
> 
> > -Original Message-
> > From: Boeuf, Sebastien 
> > Sent: Wednesday, February 23, 2022 10:03 PM
> > To: kra...@redhat.com; Yao, Jiewen ;
> > devel@edk2.groups.io
> > Cc: Justen, Jordan L 
> > Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot
> > specification
> > 
> > On Wed, 2022-02-23 at 13:11 +, Yao, Jiewen wrote:
> > > If you want to support PVH-only, that means you *defeature* the
> > > CloudHv in *edk2-stable202202* tag according to
> > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release
> > > -
> > Planning
> > > .
> > > I hope that is stated clearly, with justification why we choose
> > > PVH-
> > > only. Something like: "In edk2-stable202202, CloudHv supported
> > > xxx.
> > > In edk2-stable202205 or future, CloudHv for non-TDX will only
> > > support
> > > PVH, because xx. The CloudFv for TDX will continue support
> > > xxx."
> > > An ASCII table is preferred to clarify the combination.
> > 
> > Sounds good. So all the justification should be part of the
> > Bugzilla
> > issue, right?
> > 
> > BTW, completely different topic, but wouldn't it be easier to use
> > Github for tracking issues? I mean especially since it's already
> > used
> > for CI and Wiki.
> > 
> > > 
> > > If possible, please create a similar README under
> > > https://github.com/tianocore/edk2/tree/master/OvmfPkg/CloudHv to
> > > record such info. (configuration, feature, supported v.s.
> > > unsupported, URL link, how to build, how to launch, etc)
> > 
> > Of course :)
> > 
> > > 
> > > 
> > > FYI: The readme in Microvm is a good example -
> > > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Microvm/README
> > > .
> > > 
> > > Thank you
> > > Yao Jiewen
> > > 
> > > > -Original Message-
> > > > From: Boeuf, Sebastien 
> > > > Sent: Wednesday, February 23, 2022 8:20 PM
> > > > To: kra...@redhat.com; devel@edk2.groups.io
> > > > Cc: Yao, Jiewen ; Justen, Jordan L
> > > > 
> > > > Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot
> > > > specification
> > > > 
> > > > On Wed, 2022-02-23 at 13:02 +0100, kra...@redhat.com wrote:
> > > > >   Hi,
> > > > > 
> > > > > > Well that's a good question. If we expect the same target
> > > > > > (CloudHv)
> > > > > > to
> > > > > > support both TDX and non-TDX, that means the generated TDVF
> > > > > > will be
> > > > > > a
> > > > > > PVH ELF binary, which will require some special handling
> > > > > > from
> > > > > > Cloud
> > > > > > Hypervisor.
> > > > > > Having two separate targets would simplify things a lot.
> > > > > > What's
> > > > > > the
> > > > > > plan for QEMU? Will the same OVMF target cover both use
> > > > > > cases?
> > > > > 
> > > > > Yes, there will be a single binary supporting both tdx and
> > > > > non-
> > > > > tdx,
> > > > > some
> > > > > configs add sev to the mix.  Doing the same for cloudhv
> > > > > shouldn't
> > > > > be
> > > > > much
> > > > > of a problem I think.
> > > > > 
> > > > > In tdx mode the firmware uses the tdhob for memory detection,
> > > > > in
> > > > > non-
> > > > > tdx
> > > > > mode qemu fw_cfg is used instead.  The cloudhv build could
> > > > > switch
> > > > > between tdhob and pvhinfo in a simliar way.
> > > > 
> > > > Sounds good :)
> > > > 
> > > > > 
> > > > > take care,
> > > > >  Gerd
> > > > > 
> > > 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

[edk2-devel] [PATCH v2 3/5] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

2022-02-23 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  2 ++
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c   | 39 ++---
 OvmfPkg/CloudHv/CloudHvX64.fdf  |  3 ++
 OvmfPkg/Include/IndustryStandard/CloudHv.h  |  5 ---
 4 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index b36b8413e0..f22bd7cb6d 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -56,6 +56,8 @@
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
 
 [Depex]
   gEfiAcpiTableProtocolGuid
diff --git a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
index 44a6bb70fe..ff59600d3e 100644
--- a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
@@ -7,9 +7,11 @@
 
 **/
 
-#include  // CLOUDHV_RSDP_ADDRESS
-#include   // CpuDeadLoop()
-#include  // DEBUG()
+#include  // 
CLOUDHV_RSDP_ADDRESS
+#include  // hvm_start_info
+#include   // CpuDeadLoop()
+#include  // DEBUG()
+#include// PcdGet32()
 
 #include "AcpiPlatform.h"
 
@@ -23,20 +25,33 @@ InstallCloudHvTables (
   EFI_STATUS  Status;
   UINTN   TableHandle;
 
-  EFI_ACPI_DESCRIPTION_HEADER*Xsdt;
-  VOID   *CurrentTableEntry;
-  UINTN  CurrentTablePointer;
-  EFI_ACPI_DESCRIPTION_HEADER*CurrentTable;
-  UINTN  Index;
-  UINTN  NumberOfTableEntries;
-  EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE  *Fadt2Table;
-  EFI_ACPI_DESCRIPTION_HEADER*DsdtTable;
+  EFI_ACPI_DESCRIPTION_HEADER   *Xsdt;
+  VOID  *CurrentTableEntry;
+  UINTN CurrentTablePointer;
+  EFI_ACPI_DESCRIPTION_HEADER   *CurrentTable;
+  UINTN Index;
+  UINTN NumberOfTableEntries;
+  EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE *Fadt2Table;
+  EFI_ACPI_DESCRIPTION_HEADER   *DsdtTable;
+  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *AcpiRsdpStructurePtr;
+  UINT32*PVHResetVectorData;
+  struct hvm_start_info *pvh_start_info;
 
   Fadt2Table   = NULL;
   DsdtTable= NULL;
   TableHandle  = 0;
   NumberOfTableEntries = 0;
-  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *AcpiRsdpStructurePtr = (VOID 
*)CLOUDHV_RSDP_ADDRESS;
+  AcpiRsdpStructurePtr = NULL;
+  PVHResetVectorData   = NULL;
+  pvh_start_info   = NULL;
+
+  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+  if (PVHResetVectorData == 0) {
+return EFI_NOT_FOUND;
+  }
+
+  pvh_start_info   = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];
+  AcpiRsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER 
*)(UINTN)pvh_start_info->rsdp_paddr;
 
   // If XSDT table is found, just install its tables.
   // Otherwise, try to find and install the RSDT tables.
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index 8eebcf..9db03380a1 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -184,6 +184,9 @@ 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|gUefiOvmfPkgTokenSpaceGuid.PcdO
 0x00E000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
 
+0x00F000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
diff --git a/OvmfPkg/Include/IndustryStandard/CloudHv.h 
b/OvmfPkg/Include/IndustryStandard/CloudHv.h
index 86404cc97e..d31ecc9eec 100644
--- a/OvmfPkg/Include/IndustryStandard/CloudHv.h
+++ b/OvmfPkg/Include/IndustryStandard/CloudHv.h
@@ -38,9 +38,4 @@
 //
 #define CLOUDHV_SMBIOS_ADDRESS  0xf
 
-//
-// RSDP address
-//
-#define CLOUDHV_RSDP_ADDRESS  0xa
-
 #endif // __CLOUDHV_H__
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196

[edk2-devel] [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible

2022-02-23 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Adding some flexibility to the program so that other targets can use it
if needed.

An optional size parameter is added so that we can provide the expected
blob size of the generated binary.

A global define is added so that we can choose at build time if we want
to use 32-bit or 64-bit bases structures.

The default behavior isn't modified.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/OvmfXenElfHeaderGenerator.c | 63 -
 1 file changed, 52 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/OvmfXenElfHeaderGenerator.c 
b/OvmfPkg/OvmfXenElfHeaderGenerator.c
index 489060cdad..a054c77cda 100644
--- a/OvmfPkg/OvmfXenElfHeaderGenerator.c
+++ b/OvmfPkg/OvmfXenElfHeaderGenerator.c
@@ -12,6 +12,7 @@
 #include "elf.h"
 #include "stdio.h"
 #include "stddef.h"
+#include "stdlib.h"
 
 void
 print_hdr (
@@ -38,7 +39,8 @@ typedef struct {
 
 int
 main (
-  void
+  int   argc,
+  char  *argv[]
   )
 {
   /* FW_SIZE */
@@ -47,23 +49,46 @@ main (
   uint32_t  ovmf_base_address = 0x0010;
   /* Xen PVH entry point */
   uint32_t  ovmfxen_pvh_entry_point = ovmf_base_address + ovmf_blob_size - 
0x30;
-  size_toffset_into_file= 0;
+  size_toffset_into_file = 0;
+  char  *endptr, *str;
+  long  param;
+
+  /* Parse the size parameter */
+  if (argc > 1) {
+str   = argv[1];
+param = strtol (str, , 10);
+if (endptr != str) {
+  ovmf_blob_size = (size_t)param;
+}
+  }
 
   /* ELF file header */
+ #ifdef PVH64
+  Elf64_Ehdr  hdr = {
+ #else
   Elf32_Ehdr  hdr = {
-.e_ident = ELFMAG,
-.e_type  = ET_EXEC,
-.e_machine   = EM_386,
-.e_version   = EV_CURRENT,
-.e_entry = ovmfxen_pvh_entry_point,
-.e_flags = R_386_NONE,
-.e_ehsize= sizeof (hdr),
+ #endif
+.e_ident   = ELFMAG,
+.e_type= ET_EXEC,
+.e_machine = EM_386,
+.e_version = EV_CURRENT,
+.e_entry   = ovmfxen_pvh_entry_point,
+.e_flags   = R_386_NONE,
+.e_ehsize  = sizeof (hdr),
+ #ifdef PVH64
+.e_phentsize = sizeof (Elf64_Phdr),
+ #else
 .e_phentsize = sizeof (Elf32_Phdr),
+ #endif
   };
 
   offset_into_file += sizeof (hdr);
 
-  hdr.e_ident[EI_CLASS]   = ELFCLASS32;
+ #ifdef PVH64
+  hdr.e_ident[EI_CLASS] = ELFCLASS64;
+ #else
+  hdr.e_ident[EI_CLASS] = ELFCLASS32;
+ #endif
   hdr.e_ident[EI_DATA]= ELFDATA2LSB;
   hdr.e_ident[EI_VERSION] = EV_CURRENT;
   hdr.e_ident[EI_OSABI]   = ELFOSABI_LINUX;
@@ -71,14 +96,22 @@ main (
   hdr.e_phoff = sizeof (hdr);
 
   /* program header */
+ #ifdef PVH64
+  Elf64_Phdr  phdr_load = {
+ #else
   Elf32_Phdr  phdr_load = {
+ #endif
 .p_type   = PT_LOAD,
 .p_offset = 0, /* load everything */
 .p_paddr  = ovmf_base_address,
 .p_filesz = ovmf_blob_size,
 .p_memsz  = ovmf_blob_size,
 .p_flags  = PF_X | PF_W | PF_R,
+ #ifdef PVH64
+.p_align  = 4,
+ #else
 .p_align  = 0,
+ #endif
   };
 
   phdr_load.p_vaddr = phdr_load.p_paddr;
@@ -98,12 +131,20 @@ main (
   sizeof (xen_elfnote_phys32_entry) -
   offsetof (xen_elfnote_phys32_entry, desc),
   };
-  Elf32_Phdrphdr_note = {
+ #ifdef PVH64
+  Elf64_Phdr  phdr_note = {
+ #else
+  Elf32_Phdr  phdr_note = {
+ #endif
 .p_type   = PT_NOTE,
 .p_filesz = sizeof (xen_elf_note),
 .p_memsz  = sizeof (xen_elf_note),
 .p_flags  = PF_R,
+ #ifdef PVH64
+.p_align  = 4,
+ #else
 .p_align  = 0,
+ #endif
   };
 
   hdr.e_phnum   += 1;
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



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

[edk2-devel] [PATCH v2 5/5] OvmfPkg: CloudHv: Add README

2022-02-23 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/CloudHv/README | 66 ++
 1 file changed, 66 insertions(+)
 create mode 100644 OvmfPkg/CloudHv/README

diff --git a/OvmfPkg/CloudHv/README b/OvmfPkg/CloudHv/README
new file mode 100644
index 00..ffd4f19c50
--- /dev/null
+++ b/OvmfPkg/CloudHv/README
@@ -0,0 +1,66 @@
+
+CloudHv is a port of OVMF for the Cloud Hypervisor project.
+
+The Cloud Hypervisor project
+
+
+Cloud Hypervisor is a Virtual Machine Monitor that runs on top of KVM. The
+project focuses on exclusively running modern, cloud workloads, on top of a
+limited set of hardware architectures and platforms. Cloud workloads refers to
+those that are usually run by customers inside a cloud provider. This means
+modern operating systems with most I/O handled by paravirtualised devices
+(i.e. virtio), no requirement for legacy devices, and 64-bit CPUs.
+
+https://github.com/cloud-hypervisor/cloud-hypervisor
+
+Design
+--
+
+Based on Cloud Hypervisor's motto to reduce the emulation as much as possible,
+the project logically decided to support the PVH boot specification as the only
+way of booting virtual machines. That includes both direct kernel boot and OVMF
+firmware which must be generated as PVH ELF binaries.
+PVH allows information like location of ACPI tables and location of guest RAM
+ranges to be shared without the need of an extra emulated device like a CMOS.
+
+Features
+
+
+* Serial console
+* EFI shell
+* virtio-pci
+
+Build
+-
+
+The way to build the CloudHv target is as follows:
+
+OvmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG
+
+Usage
+-
+
+Assuming Cloud Hypervisor is already built, one can start a virtual machine as
+follows:
+
+./cloud-hypervisor \
+--cpus boot=1 \
+--memory size=1G \
+--kernel Build/CloudHvX64/DEBUG_GCC5/FV/CLOUDHV.fd \
+--disk path=/path/to/disk.raw
+
+Releases
+
+
+In edk2-stable202202, CloudHv is generated as data-only binary.
+Starting with edk2-stable202205, CloudHv is generated as a PVH ELF binary to
+reduce the amount of emulation needed from Cloud Hypervisor.
+For TDX, things are handled differently and PVH is not used, which is why the
+firmware is always generated as a data-only binary.
+
++---++-+
+|  CloudHv  |non-TDX | TDX |
++---++-+
+| edk2-stable202202 | Data binary| Data binary |
+| edk2-stable202205 | PVH ELF binary | Data binary |
++---++-+
\ No newline at end of file
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



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

[edk2-devel] [PATCH v2 0/5] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Cloud Hypervisor aims at emulating the minimal amount of legacy devices
and this is why the PVH boot specification is supported. The point is to
be able to share some information with the guest without the need for
emulating devices that would be present on real hardware.

Since Cloud Hypervisor supports loading a PVH ELF binary, the CloudHv
target is updated to be generated as such. Relying on the PVH boot
specification, we don't need to hardcode the location of the ACPI tables
anymore since we can retrieve the RSDP address from the hvm_start_info
structure. Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.

Signed-off-by: Sebastien Boeuf 

Sebastien Boeuf (5):
  OvmfPkg: Make the Xen ELF header generator more flexible
  OvmfPkg: Generate CloudHv as a PVH ELF binary
  OvmfPkg: CloudHv: Retrieve RSDP address from PVH
  OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS
  OvmfPkg: CloudHv: Add README

 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  2 +
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c   | 39 ++---
 OvmfPkg/CloudHv/CloudHvX64.dsc  |  2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf  | 97 -
 OvmfPkg/CloudHv/README  | 66 ++
 OvmfPkg/Include/IndustryStandard/CloudHv.h  |  5 --
 OvmfPkg/OvmfXenElfHeaderGenerator.c | 63 ++---
 OvmfPkg/PlatformPei/MemDetect.c | 73 
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 +
 9 files changed, 318 insertions(+), 31 deletions(-)
 create mode 100644 OvmfPkg/CloudHv/README

-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Yao, Jiewen

Yes, justification in bugzilla and README, please.

I suggestion you send a different email to ask the different topic - not 
distract people.


> -Original Message-
> From: Boeuf, Sebastien 
> Sent: Wednesday, February 23, 2022 10:03 PM
> To: kra...@redhat.com; Yao, Jiewen ;
> devel@edk2.groups.io
> Cc: Justen, Jordan L 
> Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification
> 
> On Wed, 2022-02-23 at 13:11 +, Yao, Jiewen wrote:
> > If you want to support PVH-only, that means you *defeature* the
> > CloudHv in *edk2-stable202202* tag according to
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
> Planning
> > .
> > I hope that is stated clearly, with justification why we choose PVH-
> > only. Something like: "In edk2-stable202202, CloudHv supported xxx.
> > In edk2-stable202205 or future, CloudHv for non-TDX will only support
> > PVH, because xx. The CloudFv for TDX will continue support xxx."
> > An ASCII table is preferred to clarify the combination.
> 
> Sounds good. So all the justification should be part of the Bugzilla
> issue, right?
> 
> BTW, completely different topic, but wouldn't it be easier to use
> Github for tracking issues? I mean especially since it's already used
> for CI and Wiki.
> 
> >
> > If possible, please create a similar README under
> > https://github.com/tianocore/edk2/tree/master/OvmfPkg/CloudHv to
> > record such info. (configuration, feature, supported v.s.
> > unsupported, URL link, how to build, how to launch, etc)
> 
> Of course :)
> 
> >
> >
> > FYI: The readme in Microvm is a good example -
> > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Microvm/README.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Boeuf, Sebastien 
> > > Sent: Wednesday, February 23, 2022 8:20 PM
> > > To: kra...@redhat.com; devel@edk2.groups.io
> > > Cc: Yao, Jiewen ; Justen, Jordan L
> > > 
> > > Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot
> > > specification
> > >
> > > On Wed, 2022-02-23 at 13:02 +0100, kra...@redhat.com wrote:
> > > >   Hi,
> > > >
> > > > > Well that's a good question. If we expect the same target
> > > > > (CloudHv)
> > > > > to
> > > > > support both TDX and non-TDX, that means the generated TDVF
> > > > > will be
> > > > > a
> > > > > PVH ELF binary, which will require some special handling from
> > > > > Cloud
> > > > > Hypervisor.
> > > > > Having two separate targets would simplify things a lot. What's
> > > > > the
> > > > > plan for QEMU? Will the same OVMF target cover both use cases?
> > > >
> > > > Yes, there will be a single binary supporting both tdx and non-
> > > > tdx,
> > > > some
> > > > configs add sev to the mix.  Doing the same for cloudhv shouldn't
> > > > be
> > > > much
> > > > of a problem I think.
> > > >
> > > > In tdx mode the firmware uses the tdhob for memory detection, in
> > > > non-
> > > > tdx
> > > > mode qemu fw_cfg is used instead.  The cloudhv build could switch
> > > > between tdhob and pvhinfo in a simliar way.
> > >
> > > Sounds good :)
> > >
> > > >
> > > > take care,
> > > >  Gerd
> > > >
> >



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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Boeuf, Sebastien

On Wed, 2022-02-23 at 13:11 +, Yao, Jiewen wrote:
> If you want to support PVH-only, that means you *defeature* the
> CloudHv in *edk2-stable202202* tag according to
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> .
> I hope that is stated clearly, with justification why we choose PVH-
> only. Something like: "In edk2-stable202202, CloudHv supported xxx.
> In edk2-stable202205 or future, CloudHv for non-TDX will only support
> PVH, because xx. The CloudFv for TDX will continue support xxx."
> An ASCII table is preferred to clarify the combination.

Sounds good. So all the justification should be part of the Bugzilla
issue, right?

BTW, completely different topic, but wouldn't it be easier to use
Github for tracking issues? I mean especially since it's already used
for CI and Wiki.

> 
> If possible, please create a similar README under
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/CloudHv to
> record such info. (configuration, feature, supported v.s.
> unsupported, URL link, how to build, how to launch, etc)

Of course :)

> 
> 
> FYI: The readme in Microvm is a good example -
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Microvm/README.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Boeuf, Sebastien 
> > Sent: Wednesday, February 23, 2022 8:20 PM
> > To: kra...@redhat.com; devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Justen, Jordan L
> > 
> > Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot
> > specification
> > 
> > On Wed, 2022-02-23 at 13:02 +0100, kra...@redhat.com wrote:
> > >   Hi,
> > > 
> > > > Well that's a good question. If we expect the same target
> > > > (CloudHv)
> > > > to
> > > > support both TDX and non-TDX, that means the generated TDVF
> > > > will be
> > > > a
> > > > PVH ELF binary, which will require some special handling from
> > > > Cloud
> > > > Hypervisor.
> > > > Having two separate targets would simplify things a lot. What's
> > > > the
> > > > plan for QEMU? Will the same OVMF target cover both use cases?
> > > 
> > > Yes, there will be a single binary supporting both tdx and non-
> > > tdx,
> > > some
> > > configs add sev to the mix.  Doing the same for cloudhv shouldn't
> > > be
> > > much
> > > of a problem I think.
> > > 
> > > In tdx mode the firmware uses the tdhob for memory detection, in
> > > non-
> > > tdx
> > > mode qemu fw_cfg is used instead.  The cloudhv build could switch
> > > between tdhob and pvhinfo in a simliar way.
> > 
> > Sounds good :)
> > 
> > > 
> > > take care,
> > >  Gerd
> > > 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Yao, Jiewen

If you want to support PVH-only, that means you *defeature* the CloudHv in 
*edk2-stable202202* tag according to 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.
I hope that is stated clearly, with justification why we choose PVH-only. 
Something like: "In edk2-stable202202, CloudHv supported xxx. In 
edk2-stable202205 or future, CloudHv for non-TDX will only support PVH, because 
xx. The CloudFv for TDX will continue support xxx." An ASCII table is 
preferred to clarify the combination.

If possible, please create a similar README under 
https://github.com/tianocore/edk2/tree/master/OvmfPkg/CloudHv to record such 
info. (configuration, feature, supported v.s. unsupported, URL link, how to 
build, how to launch, etc)

FYI: The readme in Microvm is a good example - 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Microvm/README.

Thank you
Yao Jiewen

> -Original Message-
> From: Boeuf, Sebastien 
> Sent: Wednesday, February 23, 2022 8:20 PM
> To: kra...@redhat.com; devel@edk2.groups.io
> Cc: Yao, Jiewen ; Justen, Jordan L
> 
> Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification
> 
> On Wed, 2022-02-23 at 13:02 +0100, kra...@redhat.com wrote:
> >   Hi,
> >
> > > Well that's a good question. If we expect the same target (CloudHv)
> > > to
> > > support both TDX and non-TDX, that means the generated TDVF will be
> > > a
> > > PVH ELF binary, which will require some special handling from Cloud
> > > Hypervisor.
> > > Having two separate targets would simplify things a lot. What's the
> > > plan for QEMU? Will the same OVMF target cover both use cases?
> >
> > Yes, there will be a single binary supporting both tdx and non-tdx,
> > some
> > configs add sev to the mix.  Doing the same for cloudhv shouldn't be
> > much
> > of a problem I think.
> >
> > In tdx mode the firmware uses the tdhob for memory detection, in non-
> > tdx
> > mode qemu fw_cfg is used instead.  The cloudhv build could switch
> > between tdhob and pvhinfo in a simliar way.
> 
> Sounds good :)
> 
> >
> > take care,
> >  Gerd
> >

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

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg: Extend SMM CPU Service with rendezvous support.

2022-02-23 Thread Li, Zhihao

Send patch v4 following Siyuan comments.

> -Original Message-
> From: Fu, Siyuan 
> Sent: Wednesday, February 23, 2022 6:20 PM
> To: devel@edk2.groups.io; Li, Zhihao 
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul1 
> Subject: RE: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg: Extend SMM CPU
> Service with rendezvous support.
> 
> Hi, Zhihao
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Li,
> > Zhihao
> > Sent: 2022年2月23日 14:42
> > To: devel@edk2.groups.io
> > Cc: Dong, Eric ; Ni, Ray ;
> > Kumar,
> > Rahul1 ; Fu, Siyuan 
> > Subject: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg: Extend SMM CPU
> > Service with rendezvous support.
> >
> > REF： https://bugzilla.tianocore.org/show_bug.cgi?id=3815
> >
> > This patch define a new Protocol with the new services
> > SmmWaitForAllProcessor(), which can be used by SMI handler to
> > optionally wait for other APs to complete SMM rendezvous in relaxed AP
> > mode.
> >
> > A new library SmmCpuRendezvousLib is provided to abstract the service
> > into library API to simple SMI handler code.
> >
> > Patch_v3 modified to pass CI test. (1)Add SmmCpuRendezvousLib.inf into
> > UefiCpuPkg.dsc / (2)Add
> > SmmCpuRendezvousLib.h in UefiCpuPkg.dec [Libraryclasses.IA32,
> > Libraryclasses.x64] (3) Some UncrustifyCheck modifications.
> >
> > Cc: Eric Dong 
> > Cc: Ray Ni 
> > Cc: Rahul Kumar 
> > Cc: Siyuan Fu 
> >
> > Signed-off-by: Zhihao Li 
> > ---
> >  UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c   |
> 98
> > 
> >  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 68
> > +-
> >  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 15 ++-
> >  UefiCpuPkg/Include/Library/SmmCpuRendezvousLib.h   | 27 ++
> >  UefiCpuPkg/Include/Protocol/SmmCpuService.h| 36 ++-
> >  UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.inf |
> 35
> > +++
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 30
> +-
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |  5 +-
> >  UefiCpuPkg/UefiCpuPkg.dec  |  8 +-
> >  UefiCpuPkg/UefiCpuPkg.dsc  |  2 +
> >  10 files changed, 314 insertions(+), 10 deletions(-)
> >
> > diff --git
> > a/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
> > b/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
> > new file mode 100644
> > index ..a53a5a8f301a
> > --- /dev/null
> > +++
> b/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
> > @@ -0,0 +1,98 @@
> > +/** @file
> >
> > +  SMM CPU Rendezvous sevice implement.
> >
> > +
> >
> > +  Copyright (c) 2021 - 2022, Intel Corporation. All rights
> > + reserved.
> >
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> > +
> >
> > +**/
> >
> > +
> >
> > +#include 
> >
> > +#include 
> >
> > +#include 
> >
> > +#include 
> >
> > +#include 
> >
> > +#include 
> >
> > +#include 
> >
> > +
> >
> > +STATIC EDKII_SMM_CPU_RENDEZVOUS_PROTOCOL
> *mSmmCpuRendezvous =
> > NULL;
> >
> > +STATIC VOID   *mRegistration = NULL;
> >
> > +
> >
> > +/**
> >
> > +  Register status code callback function only when Report Status Code
> > + protocol
> >
> > +  is installed.
> >
> > +
> >
> > +  @param[in] Protocol   Points to the protocol's unique identifier.
> >
> > +  @param[in] Interface  Points to the interface instance.
> >
> > +  @param[in] Handle The handle on which the interface was installed.
> >
> > +
> >
> > +  @retval EFI_SUCCESS  Notification runs successfully.
> >
> > +
> >
> > +**/
> >
> > +EFI_STATUS
> >
> > +EFIAPI
> >
> > +SmmCpuRendezvousProtocolNotify (
> >
> > +  IN CONST EFI_GUID*Protocol,
> >
> > +  IN   VOID*Interface,
> >
> > +  IN   EFI_HANDLE  Handle
> >
> > +  )
> >
> > +{
> >
> > +  EFI_STATUS  Status;
> >
> > +
> >
> > +  Status = gMmst->MmLocateProtocol (
> >
> > +,
> >
> > +NULL,
> >
> > +(VOID **)
> >
> > +);
> >
> > +  ASSERT_EFI_ERROR (Status);
> >
> > +
> >
> > +  return EFI_SUCCESS;
> >
> > +}
> >
> > +
> >
> > +/**
> >
> > +  This routine wait for all AP processors to arrive in SMM.
> >
> > +
> >
> > +  @param[in] BlockingMode  Blocking mode or non-blocking mode.
> >
> > +
> >
> > +  @retval EFI_SUCCESS  All avaiable APs arrived.
> >
> > +  @retval EFI_TIMEOUT  Wait for all APs until timeout.
> >
> > +  @retval OTHERFail to register SMM CPU Rendezvous service 
> > Protocol.
> >
> > +**/
> >
> > +EFI_STATUS
> >
> > +EFIAPI
> >
> > +SmmWaitForAllProcessor (
> >
> > +  IN BOOLEAN  BlockingMode
> >
> > +  )
> >
> > +{
> >
> > +  EFI_STATUS  Status;
> >
> > +
> >
> > +  if ((mRegistration == NULL) && (mSmmCpuRendezvous == NULL)) {
> >
> > +//
> >
> > +// Locate SMM cpu rendezvous protocol for the first time execute
> > + the
> > function.
> >
> > +//
> >

[edk2-devel] [PATCH v4 1/1] UefiCpuPkg: Extend SMM CPU Service with rendezvous support.

2022-02-23 Thread Li, Zhihao

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

This patch define a new Protocol with the new services
SmmWaitForAllProcessor(), which can be used by SMI handler
to optionally wait for other APs to complete SMM rendezvous in
relaxed AP mode.

A new library SmmCpuRendezvousLib is provided to abstract the service
into library API to simple SMI handler code.

Patch_v3 modified to pass CI test. (1)Add SmmCpuRendezvousLib.inf into
UefiCpuPkg.dsc / (2)Add SmmCpuRendezvousLib.h
in UefiCpuPkg.dec [Libraryclasses.IA32, Libraryclasses.x64] (3) Some
UncrustifyCheck modifications.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Siyuan Fu 

Signed-off-by: Zhihao Li 
---
 UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c   | 98 

 UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 68 
+-
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 20 +++-
 UefiCpuPkg/Include/Library/SmmCpuRendezvousLib.h   | 27 ++
 UefiCpuPkg/Include/Protocol/SmmCpuService.h| 36 ++-
 UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.inf | 35 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 29 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |  5 +-
 UefiCpuPkg/UefiCpuPkg.dec  |  8 +-
 UefiCpuPkg/UefiCpuPkg.dsc  |  2 +
 10 files changed, 316 insertions(+), 12 deletions(-)

diff --git a/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c 
b/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
new file mode 100644
index ..22f694b77d51
--- /dev/null
+++ b/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
@@ -0,0 +1,98 @@
+/** @file

+  SMM CPU Rendezvous sevice implement.

+

+  Copyright (c) 2022, Intel Corporation. All rights reserved.

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

+

+**/

+

+#include 

+#include 

+#include 

+#include 

+#include 

+#include 

+#include 

+

+STATIC EDKII_SMM_CPU_RENDEZVOUS_PROTOCOL  *mSmmCpuRendezvous = NULL;

+STATIC VOID   *mRegistration = NULL;

+

+/**

+  Register status code callback function only when Report Status Code protocol

+  is installed.

+

+  @param[in] Protocol   Points to the protocol's unique identifier.

+  @param[in] Interface  Points to the interface instance.

+  @param[in] Handle The handle on which the interface was installed.

+

+  @retval EFI_SUCCESS  Notification runs successfully.

+

+**/

+EFI_STATUS

+EFIAPI

+SmmCpuRendezvousProtocolNotify (

+  IN CONST EFI_GUID*Protocol,

+  IN   VOID*Interface,

+  IN   EFI_HANDLE  Handle

+  )

+{

+  EFI_STATUS  Status;

+

+  Status = gMmst->MmLocateProtocol (

+,

+NULL,

+(VOID **)

+);

+  ASSERT_EFI_ERROR (Status);

+

+  return EFI_SUCCESS;

+}

+

+/**

+  This routine wait for all AP processors to arrive in SMM.

+

+  @param[in] BlockingMode  Blocking mode or non-blocking mode.

+

+  @retval EFI_SUCCESS  All avaiable APs arrived.

+  @retval EFI_TIMEOUT  Wait for all APs until timeout.

+  @retval OTHERFail to register SMM CPU Rendezvous service Protocol.

+**/

+EFI_STATUS

+EFIAPI

+SmmWaitForAllProcessor (

+  IN BOOLEAN  BlockingMode

+  )

+{

+  EFI_STATUS  Status;

+

+  if ((mRegistration == NULL) && (mSmmCpuRendezvous == NULL)) {

+//

+// Locate SMM cpu rendezvous protocol for the first time execute the 
function.

+//

+Status = gMmst->MmLocateProtocol (

+  ,

+  NULL,

+  (VOID **)

+  );

+if (EFI_ERROR (Status)) {

+  Status = gMmst->MmRegisterProtocolNotify (

+,

+SmmCpuRendezvousProtocolNotify,

+

+);

+  if (EFI_ERROR (Status)) {

+return Status;

+  }

+}

+  }

+

+  if (mSmmCpuRendezvous == NULL) {

+return EFI_SUCCESS;

+  }

+

+  Status = mSmmCpuRendezvous->WaitForAllProcessor (

+mSmmCpuRendezvous,

+BlockingMode

+);

+  return Status;

+}

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
index 5d624f8e9ed6..e096970ac62e 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
@@ -1,7 +1,7 @@
 /** @file

 Implementation of SMM CPU Services Protocol.

 

-Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.

+Copyright (c) 2011 - 2022, Intel Corporation. All rights reserved.

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

 

 **/

@@ -20,6 +20,13 @@ EFI_SMM_CPU_SERVICE_PROTOCOL  mSmmCpuService = {
   SmmRegisterExceptionHandler

 };

 

+//

+// EDKII SMM CPU

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

2022-02-23 Thread Boeuf, Sebastien

On Wed, 2022-02-23 at 12:22 +0100, Gerd Hoffmann wrote:
> On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> > From: Sebastien Boeuf 
> > 
> > Following the model from the Xen target, CloudHv is generated as a
> > PVH
> > ELF binary to take advantage of the PVH specification.
> 
> > --- /dev/null
> > +++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> 
> Why create a new copy of this?  What are the differences to the Xen
> version?  I guess they are small so we can maybe have a common
> ElfPvhHeaderGenerator.c with command line switches?

That's right, I can work on updating the generator to take some
parameters so that I won't need the duplication of the file.

> 
> > -  OvmfPkg/ResetVector/ResetVector.inf
> > +  OvmfPkg/XenResetVector/XenResetVector.inf
> 
> Why this is needed?

It stores the "Start of day" structure pointer, which is then used by
some follow up patches to access hvm_start_info structure (containing
the PVH boot information).

> 
> > +DATA = {
> > +  #
> > +  # This hex array have been generated by
> > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > +  # and copied manually.
> 
> How about having the generator write a .fdf.inc file which you can
> just
> include directly without manual copying?

I understand the idea, but do you have any pointer to some existing
code in the repo already doing such thing?

Thanks,
Sebastien

> 
> take care,
>   Gerd
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Boeuf, Sebastien

On Wed, 2022-02-23 at 13:02 +0100, kra...@redhat.com wrote:
>   Hi,
> 
> > Well that's a good question. If we expect the same target (CloudHv)
> > to
> > support both TDX and non-TDX, that means the generated TDVF will be
> > a
> > PVH ELF binary, which will require some special handling from Cloud
> > Hypervisor.
> > Having two separate targets would simplify things a lot. What's the
> > plan for QEMU? Will the same OVMF target cover both use cases?
> 
> Yes, there will be a single binary supporting both tdx and non-tdx,
> some
> configs add sev to the mix.  Doing the same for cloudhv shouldn't be
> much
> of a problem I think.
> 
> In tdx mode the firmware uses the tdhob for memory detection, in non-
> tdx
> mode qemu fw_cfg is used instead.  The cloudhv build could switch
> between tdhob and pvhinfo in a simliar way.

Sounds good :)

> 
> take care,
>  Gerd
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Gerd Hoffmann

  Hi,

> Well that's a good question. If we expect the same target (CloudHv) to
> support both TDX and non-TDX, that means the generated TDVF will be a
> PVH ELF binary, which will require some special handling from Cloud
> Hypervisor.
> Having two separate targets would simplify things a lot. What's the
> plan for QEMU? Will the same OVMF target cover both use cases?

Yes, there will be a single binary supporting both tdx and non-tdx, some
configs add sev to the mix.  Doing the same for cloudhv shouldn't be much
of a problem I think.

In tdx mode the firmware uses the tdhob for memory detection, in non-tdx
mode qemu fw_cfg is used instead.  The cloudhv build could switch
between tdhob and pvhinfo in a simliar way.

take care,
 Gerd



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

Re: [edk2-devel] [PATCH V6 33/42] OvmfPkg: Update PlatformInitLib for Tdx guest to publish ram regions

2022-02-23 Thread Gerd Hoffmann

On Wed, Feb 23, 2022 at 10:49:08AM +, Yao, Jiewen wrote:
> I think both are correct.

> Section 10.1.2, Table 10.1 - RBX[5:0] is GPAW - only 48 and 52 are possible.

Ok.
Acked-by: Gerd Hoffmann 

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86901): https://edk2.groups.io/g/devel/message/86901
Mute This Topic: https://groups.io/mt/89252063/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] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

2022-02-23 Thread Gerd Hoffmann

  Hi,

> +  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 
> (PcdXenPvhStartOfDayStructPtr);
> +  pvh_start_info   = (struct hvm_start_info 
> *)(UINTN)PVHResetVectorData[0];

Ah, I see, here is the xen reset vector dependency.

I'm wondering whenever there are plans for cloudhv to also support sev
and/or tdx some day.  If so, then it probably isn't a good idea to
switch to the xen reset vector.  There is the work area used for by
confidential computing code, I think it would be an option to store a
pointer to the pvh_start_info there.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86900): https://edk2.groups.io/g/devel/message/86900
Mute This Topic: https://groups.io/mt/89319394/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] OvmfPkg: Generate CloudHv as a PVH ELF binary

2022-02-23 Thread Gerd Hoffmann

On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> From: Sebastien Boeuf 
> 
> Following the model from the Xen target, CloudHv is generated as a PVH
> ELF binary to take advantage of the PVH specification.

> --- /dev/null
> +++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c

Why create a new copy of this?  What are the differences to the Xen
version?  I guess they are small so we can maybe have a common
ElfPvhHeaderGenerator.c with command line switches?

> -  OvmfPkg/ResetVector/ResetVector.inf
> +  OvmfPkg/XenResetVector/XenResetVector.inf

Why this is needed?

> +DATA = {
> +  #
> +  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
> +  # and copied manually.

How about having the generator write a .fdf.inc file which you can just
include directly without manual copying?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86899): https://edk2.groups.io/g/devel/message/86899
Mute This Topic: https://groups.io/mt/89319391/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 8/8] OvmfPkg: Introduce IntelTdxX64 for TDVF Config-B

2022-02-23 Thread Gerd Hoffmann

  Hi,

> +  #
> +  # Defines for default states.  These can be changed on the command line.
> +  # -D FLAG=VALUE
> +  #
> +  DEFINE SECURE_BOOT_ENABLE  = FALSE

Will TDX support secure boot?  If not then this config switch can simply
be dropped (and the checks for SECURE_BOOT_ENABLE too).

Given this is just a minor cleanup:
Acked-by: Gerd Hoffmann 

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86898): https://edk2.groups.io/g/devel/message/86898
Mute This Topic: https://groups.io/mt/89266124/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 7/8] OvmfPkg: Update DxeAcpiTimerLib to read HostBridgeDevId in PlatformInfoHob

2022-02-23 Thread Gerd Hoffmann

>//
>// Query Host Bridge DID to determine platform type
> +  // Tdx guest stores the HostBridgePciDevId in a GuidHob.
> +  // So we first check if this HOB exists
>//
> -  HostBridgeDevId = PcdGet16 (PcdOvmfHostBridgePciDevId);
> +  GuidHob = GetFirstGuidHob ();
> +  if (GuidHob != NULL) {
> +PlatformInfo= (EFI_HOB_PLATFORM_INFO *)GET_GUID_HOB_DATA (GuidHob);
> +HostBridgeDevId = PlatformInfo->HostBridgePciDevId;
> +  } else {
> +HostBridgeDevId = PcdGet16 (PcdOvmfHostBridgePciDevId);
> +  }

Another thing we can probably simplify when we use a PlatformInfoHob in
both PEi and PEI-less mode.

> +[Guids]
> +  gUefiOvmfPkgTdxPlatformGuid  ## CONSUMES

name this UefiOvmfPkgPlatformInfoGuid ?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86897): https://edk2.groups.io/g/devel/message/86897
Mute This Topic: https://groups.io/mt/89266123/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 6/8] OvmfPkg: Update TdxDxe to set TDX PCDs

2022-02-23 Thread Gerd Hoffmann

On Sun, Feb 20, 2022 at 10:33:17AM +0800, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> TDX_PEI_LESS_BOOT indicates the boot without PEI phase. In this case
> settings in EFI_HOB_PLATFORM_INFO should be set to its according PCDs.
> TdxDxe driver is workable for both Legacy guest and Tdx guest. It is
> because for Legacy guest (in PEI-less boot) there should be a place
> to set the PCDs based on EFI_HOB_PLATFORM_INFO hob. TdxDxe driver is
> the right place to do this work.
> 
> Cc: Michael D Kinney 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Gerd Hoffmann 
> Signed-off-by: Min Xu 

Acked-by: Gerd Hoffmann 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86896): https://edk2.groups.io/g/devel/message/86896
Mute This Topic: https://groups.io/mt/89266122/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 5/8] OvmfPkg/IntelTdx: Add Sec to bring up both Legacy and Tdx guest

2022-02-23 Thread Gerd Hoffmann

On Sun, Feb 20, 2022 at 10:33:16AM +0800, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> OvmfPkg/IntelTdx/Sec is a simplied version of OvmfPkg/Sec. There
> are below differences between these 2 Sec
>  - IntelTdx/Sec only supports Legacy guest and Tdx guest in X64.
>  - IntelTdx/Sec calls TdxStartup () to jump from SEC to DXE directly.
>  - IntelTdx/Sec uses MemoryAllocationLib / HobLib / PrePiLib in
>EmbeddedPkg.
> 
> Cc: Michael D Kinney 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Gerd Hoffmann 
> Signed-off-by: Min Xu 

Acked-by: Gerd Hoffmann 



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

2022-02-23 Thread Gerd Hoffmann

> +EFI_STATUS
> +EFIAPI
> +InitializePlatform (
> +  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  )
> +{

> +  Pci64Base = 0;
> +  Pci64Size = 0;
> +
> +  FirstNonAddress   = PlatformGetFirstNonAddress 
> (, , 0x8);
> +  PlatformInfoHob->PcdPciMmio64Base = Pci64Base;
> +  PlatformInfoHob->PcdPciMmio64Size = Pci64Size;

I think here are opportunities to make the differences between PEI and
PEI-less boot even smaller, by:

  (1) Allocate a PlatformInfoHob also when using PEI boot workflow.
  (2) Switch PlatformInitLib functions like PlatformGetFirstNonAddress() to
  receive a PlatformInfoHob pointer so they can update the HOB
  directly.
  (3) Add more platform info variables to PlatformInfoHob
  (FirstNonAddress, PhysMemAddressWidth for example).

But I guess that kind of improvements can also be done incrementally
after getting this upstream.  It's also easier to test that kind of
changes when we have both PEI and PEI-less variants present in the
upstream repo.  So I'm fine with deferring these changes for now.

Beside that:  The name TdxStartupLib doesn't reflect reality any more,
we should give it a better name.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V6 33/42] OvmfPkg: Update PlatformInitLib for Tdx guest to publish ram regions

2022-02-23 Thread Yao, Jiewen

I think both are correct.

The dump info is from a *client* machine in old generation - kabylake. 39 bits 
physical is good enough.

GPAW in TD is enforced by TDX-module. Please refer to
https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-module-1.0-public-spec-v0.931.pdf,
 
Section 10.1.2, Table 10.1 - RBX[5:0] is GPAW - only 48 and 52 are possible.

Thank you
Yao Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Wednesday, February 23, 2022 6:07 PM
> To: Xu, Min M 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Justen,
> Jordan L ; Brijesh Singh ;
> Aktas, Erdem ; James Bottomley
> ; Yao, Jiewen ; Tom Lendacky
> 
> Subject: Re: [edk2-devel] [PATCH V6 33/42] OvmfPkg: Update PlatformInitLib
> for Tdx guest to publish ram regions
> 
>   Hi,
> 
> > Another update is in PlatformAddressWidthInitialization. The physical
> > address width that Tdx guest supports is either 48 or 52.
> 
> Hmm.  Sure this is correct?
> 
> 48 is the max _virtual_ address space possible with 4-level paging.
> The _physical_ address space might be much smaller, like this
> (kaby lake desktop system):
> 
> # lscpu
> Architecture:x86_64
>   CPU op-mode(s):32-bit, 64-bit
>   Address sizes: 39 bits physical, 48 bits virtual
>   Byte Order:Little Endian
> 
> Maybe all TDX-capable Intel CPUs actually have >= 48 bits physical,
> so this could be fine, but please double-check.
> 
> thanks,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86893): https://edk2.groups.io/g/devel/message/86893
Mute This Topic: https://groups.io/mt/89252063/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 3/8] OvmfPkg: Update EFI_HOB_PLATFORM_INFO with more platform settings

2022-02-23 Thread Gerd Hoffmann

On Sun, Feb 20, 2022 at 10:33:14AM +0800, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> This patch-sets is to bring up Legacy guest and Tdx guest without
> PEI phase. So platform initialization has to be done in SEC phase.
> It is similar to the work of OvmfPkg/PlatformPei. In
> OvmfPkg/PlatformPei some PCDs are set during platform initialization,
> such as PcdPciMmio64Base. But in PEI-less boot, PCDs cannot be set.
> So these values are saved in EFI_HOB_PLATFORM_INFO. Then in the early
> stage of DXE phase this hob will be parsed and PCDs are set accordingly.
> 
> Cc: Michael D Kinney 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Gerd Hoffmann 
> Signed-off-by: Min Xu 

Acked-by: Gerd Hoffmann 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86892): https://edk2.groups.io/g/devel/message/86892
Mute This Topic: https://groups.io/mt/89266117/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 2/8] OvmfPkg: Add PrePiHobListPointerLibTdx

2022-02-23 Thread Gerd Hoffmann

On Sun, Feb 20, 2022 at 10:33:13AM +0800, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> This library sets / gets the Hob list pointer in TDX_WORK_AREA.
> This is because it is designed to be used in SEC where the value of
> global variable cannot be saved, so the Hob list pointer is saved
> in TDX_WORK_AREA.
> 
> TDX_WORK_AREA shares the same base address as SEV_WORK_AREA which is
> pointed by PcdSevEsWorkAreaBase. This PCD will be renamed to
> PcdCcWorkAreaBase as Gerd suggested.
> See https://edk2.groups.io/g/devel/message/86642
> 
> Cc: Michael D Kinney 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Gerd Hoffmann 
> Signed-off-by: Min Xu 

Acked-by: Gerd Hoffmann 



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

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg: Extend SMM CPU Service with rendezvous support.

2022-02-23 Thread Siyuan, Fu

Hi, Zhihao

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Li, Zhihao
> Sent: 2022年2月23日 14:42
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul1 ; Fu, Siyuan 
> Subject: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg: Extend SMM CPU Service with
> rendezvous support.
> 
> REF： https://bugzilla.tianocore.org/show_bug.cgi?id=3815
> 
> This patch define a new Protocol with the new services
> SmmWaitForAllProcessor(), which can be used by SMI handler
> to optionally wait for other APs to complete SMM rendezvous in
> relaxed AP mode.
> 
> A new library SmmCpuRendezvousLib is provided to abstract the service
> into library API to simple SMI handler code.
> 
> Patch_v3 modified to pass CI test. (1)Add SmmCpuRendezvousLib.inf into
> UefiCpuPkg.dsc / (2)Add
> SmmCpuRendezvousLib.h
> in UefiCpuPkg.dec [Libraryclasses.IA32, Libraryclasses.x64] (3) Some
> UncrustifyCheck modifications.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Siyuan Fu 
> 
> Signed-off-by: Zhihao Li 
> ---
>  UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c   | 98
> 
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 68
> +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 15 ++-
>  UefiCpuPkg/Include/Library/SmmCpuRendezvousLib.h   | 27 ++
>  UefiCpuPkg/Include/Protocol/SmmCpuService.h| 36 ++-
>  UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.inf | 35
> +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 30 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |  5 +-
>  UefiCpuPkg/UefiCpuPkg.dec  |  8 +-
>  UefiCpuPkg/UefiCpuPkg.dsc  |  2 +
>  10 files changed, 314 insertions(+), 10 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
> b/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
> new file mode 100644
> index ..a53a5a8f301a
> --- /dev/null
> +++ b/UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.c
> @@ -0,0 +1,98 @@
> +/** @file
> 
> +  SMM CPU Rendezvous sevice implement.
> 
> +
> 
> +  Copyright (c) 2021 - 2022, Intel Corporation. All rights reserved.
> 
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +
> 
> +**/
> 
> +
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +
> 
> +STATIC EDKII_SMM_CPU_RENDEZVOUS_PROTOCOL  *mSmmCpuRendezvous =
> NULL;
> 
> +STATIC VOID   *mRegistration = NULL;
> 
> +
> 
> +/**
> 
> +  Register status code callback function only when Report Status Code 
> protocol
> 
> +  is installed.
> 
> +
> 
> +  @param[in] Protocol   Points to the protocol's unique identifier.
> 
> +  @param[in] Interface  Points to the interface instance.
> 
> +  @param[in] Handle The handle on which the interface was installed.
> 
> +
> 
> +  @retval EFI_SUCCESS  Notification runs successfully.
> 
> +
> 
> +**/
> 
> +EFI_STATUS
> 
> +EFIAPI
> 
> +SmmCpuRendezvousProtocolNotify (
> 
> +  IN CONST EFI_GUID*Protocol,
> 
> +  IN   VOID*Interface,
> 
> +  IN   EFI_HANDLE  Handle
> 
> +  )
> 
> +{
> 
> +  EFI_STATUS  Status;
> 
> +
> 
> +  Status = gMmst->MmLocateProtocol (
> 
> +,
> 
> +NULL,
> 
> +(VOID **)
> 
> +);
> 
> +  ASSERT_EFI_ERROR (Status);
> 
> +
> 
> +  return EFI_SUCCESS;
> 
> +}
> 
> +
> 
> +/**
> 
> +  This routine wait for all AP processors to arrive in SMM.
> 
> +
> 
> +  @param[in] BlockingMode  Blocking mode or non-blocking mode.
> 
> +
> 
> +  @retval EFI_SUCCESS  All avaiable APs arrived.
> 
> +  @retval EFI_TIMEOUT  Wait for all APs until timeout.
> 
> +  @retval OTHERFail to register SMM CPU Rendezvous service Protocol.
> 
> +**/
> 
> +EFI_STATUS
> 
> +EFIAPI
> 
> +SmmWaitForAllProcessor (
> 
> +  IN BOOLEAN  BlockingMode
> 
> +  )
> 
> +{
> 
> +  EFI_STATUS  Status;
> 
> +
> 
> +  if ((mRegistration == NULL) && (mSmmCpuRendezvous == NULL)) {
> 
> +//
> 
> +// Locate SMM cpu rendezvous protocol for the first time execute the
> function.
> 
> +//
> 
> +Status = gMmst->MmLocateProtocol (
> 
> +  ,
> 
> +  NULL,
> 
> +  (VOID **)
> 
> +  );
> 
> +if (EFI_ERROR (Status)) {
> 
> +  Status = gMmst->MmRegisterProtocolNotify (
> 
> +,
> 
> +SmmCpuRendezvousProtocolNotify,
> 
> +
> 
> +);
> 
> +  if (EFI_ERROR (Status)) {
> 
> +return Status;
> 
> +  }
> 
> +}
> 
> +  }
> 
> +
> 
> +  if (mSmmCpuRendezvous == NULL) {
> 
> +return EFI_SUCCESS;
> 
> +  }
> 
> +
> 
> +  Status = mSmmCpuRendezvous->WaitForAllProcessor (
> 
> +

Re: [edk2-devel] [PATCH V6 34/42] OvmfPkg: Update PlatformPei to support Tdx guest

2022-02-23 Thread Gerd Hoffmann

  Hi,

> -Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
> +if (TdIsEnabled ()) {
> +  Pml4Entries = 0x200;
> +} else {
> +  Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
> +}

With the PlatformAddressWidthInitialization() update in patch #33 it
should not be needed to special-case TDX here.  You might need a check
for 5-level paging support (mPhysMemAddressWidth > 48) though, or just
cap Pml4Entries at 512 entries.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V6 33/42] OvmfPkg: Update PlatformInitLib for Tdx guest to publish ram regions

2022-02-23 Thread Gerd Hoffmann

  Hi,

> Another update is in PlatformAddressWidthInitialization. The physical
> address width that Tdx guest supports is either 48 or 52.

Hmm.  Sure this is correct?

48 is the max _virtual_ address space possible with 4-level paging.
The _physical_ address space might be much smaller, like this
(kaby lake desktop system):

# lscpu
Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 39 bits physical, 48 bits virtual
  Byte Order:Little Endian

Maybe all TDX-capable Intel CPUs actually have >= 48 bits physical,
so this could be fine, but please double-check.

thanks,
  Gerd



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

Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

2022-02-23 Thread Boeuf, Sebastien

Hi Jiewen,

On Wed, 2022-02-23 at 00:00 +, Yao, Jiewen wrote:
> HI Sebastien
> Here is some feedback.
> 
> 1) Since this seems a new feature, would you please file a Bugzilla
> https://bugzilla.tianocore.org/ ?

Ok I will. Just need to wait for my account to be created.

> 
> 2) Please also include this new feature in release plan -
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>  ?

Sure, I'll add a new entry in there, with the link to the bug in
Bugzilla.

> 
> 3) A clarification question: Do you want to *only* support PVH boot
> in CloudHv, or PVH is one option and you still support old way?

We want to support PVH only. No need for the legacy support. Unless you
can think of a good reason to do so?

> 
> 4) Please clarify if that impacts the support for TDVF.

Well that's a good question. If we expect the same target (CloudHv) to
support both TDX and non-TDX, that means the generated TDVF will be a
PVH ELF binary, which will require some special handling from Cloud
Hypervisor.
Having two separate targets would simplify things a lot. What's the
plan for QEMU? Will the same OVMF target cover both use cases?

Thanks,
Sebastien

> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: Boeuf, Sebastien 
> > Sent: Tuesday, February 22, 2022 11:53 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Justen, Jordan L
> > ; kra...@redhat.com; Boeuf, Sebastien
> > 
> > Subject: [PATCH 0/3] CloudHv: Rely on PVH boot specification
> > 
> > From: Sebastien Boeuf 
> > 
> > Cloud Hypervisor aims at emulating the minimal amount of legacy
> > devices
> > and this is why the PVH boot specification is supported. The point
> > is to
> > be able to share some information with the guest without the need
> > for
> > emulating devices that would be present on real hardware.
> > 
> > Since Cloud Hypervisor supports loading a PVH ELF binary, the
> > CloudHv
> > target is updated to be generated as such. Relying on the PVH boot
> > specification, we don't need to hardcode the location of the ACPI
> > tables
> > anymore since we can retrieve the RSDP address from the
> > hvm_start_info
> > structure. Same thing for the RAM below 4G, we can find this
> > information
> > through the PVH memmap entries rather than relying on the emulated
> > CMOS.
> > 
> > Signed-off-by: Sebastien Boeuf 
> > 
> > Sebastien Boeuf (3):
> >   OvmfPkg: Generate CloudHv as a PVH ELF binary
> >   OvmfPkg: CloudHv: Retrieve RSDP address from PVH
> >   OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS
> > 
> >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> >  OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c   |  39 +++--
> >  OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c | 150
> > 
> >  OvmfPkg/CloudHv/CloudHvX64.dsc  |   2 +-
> >  OvmfPkg/CloudHv/CloudHvX64.fdf  |  95 -
> >  OvmfPkg/Include/IndustryStandard/CloudHv.h  |   5 -
> >  OvmfPkg/PlatformPei/MemDetect.c |  73 ++
> >  OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
> >  8 files changed, 348 insertions(+), 20 deletions(-)
> >  create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> > 
> > --
> > 2.32.0
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

Re: [edk2-devel] [PATCH V6 28/42] OvmfPkg: Update Sec to support Tdx

2022-02-23 Thread Gerd Hoffmann

On Sat, Feb 19, 2022 at 07:56:41PM +0800, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> There are below major changes in this commit.
> 
> 1. SecEntry.nasm
> In TDX BSP and APs goes to the same entry point in SecEntry.nasm.
> 
> BSP initialize the temporary stack and then jumps to SecMain, just as
> legacy Ovmf does.
> 
> APs spin in a modified mailbox loop using initial mailbox structure.
> Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h.
> APs wait for command to see if the command is for me. If so execute the
> command.
> 
> 2. Sec/SecMain.c
> When host VMM create the Td guest, the system memory informations are
> stored in TdHob, which is a memory region described in Tdx metadata.
> The system memory region in TdHob should be accepted before it can be
> accessed. So the major task of this patch is to process the TdHobList
> to accept the memory. After that TDVF follow the standard OVMF flow
> and jump to PEI phase.
> 
> PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives
> no chance for Intel TDX to support 1G page table. To support 1G page
> table this PCD is set to TRUE in OvmfPkgX64.dsc.
> 
> TDX only works on X64, so the code is only valid in X64 arch.

Acked-by: Gerd Hoffmann 

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V6 27/42] OvmfPkg/Sec: Declare local variable as volatile in SecCoreStartupWithStack

2022-02-23 Thread Gerd Hoffmann

  Hi,

> +// Declare the local variables that actually move the data elements as
> +// volatile to prevent the optimizer from replacing this function with
> +// the intrinsic memcpy()

Oh, this intrinsics thing again ...

Looking into that right now,
sneak preview wip branch @ https://github.com/kraxel/edk2/commits/intrinsics 

But with this being a separate patch it's an easy revert should we not
need it any more, so

Acked-by: Gerd Hoffmann 

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V6 26/42] OvmfPkg: Add null instance of PlatformInitLib

2022-02-23 Thread Gerd Hoffmann

On Wed, Feb 23, 2022 at 12:34:21AM +, Min Xu wrote:
> On February 22, 2022 9:10 PM, Gerd Hoffmann wrote:
> > >
> > > Add null instance of PlatformInitLib.
> > 
> > What is this library needed for?
> 
> In #25 (OvmfPkg: Update PlatformInitLib to process Tdx hoblist) 
> ProcessTdxHobList is added in PlatformInitLib to process the Tdx HobList. 
> This function is called in OvmfPkg/Sec/SecMain.c (#28 OvmfPkg: Update Sec to 
> support Tdx). ProcessTdxHobList is called by OvmfPkg/IntelTdx/Sec/SecMain.c 
> as well. See https://edk2.groups.io/g/devel/message/86120
> 
> OvmfPkg/Sec/SecMain.c is used by 
> OvmfXen.dsc/AmdSevX64.dsc/BhyveX64.dsc/CloudHvX64.dsc/MicrovmX64.dsc. So 
> PlatformInitLibNull is needed by these platforms.

OK.  So this is probably temporary thing until the other ovmf variants
are switched over to use PlatformInitLib too?  If so, can you add a
comment saying so?

With that added:
Acked-by: Gerd Hoffmann 



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

72 matches

Mail list logo