1. devel@edk2.groups.io
  2. Messages
   Date   
Re: [PATCH] OvmfPkg/BhyveBhfPkg: install bhyve's ACPI tables

Peter Grehan
 

It's much easier to create configuration dependend ACPI tables for > bhyve than for OVMF. For this reason, don't use the statically>
created ACPI tables provided by OVMF. Instead use the dynamically> created ACPI tables of bhyve. If bhyve provides no ACPI tables or> we are unable to detect those, fall back to OVMF tables.
This looks fine though bhyve will need to generate MCFG to get to full parity.

I've requested in the past that you do this so I'll request again: please discuss these changes on the freebsd-virtualization list before sending patches outside of the project.

Acked-by: Peter Grehan <grehan@...>

later,

Peter.
Re: [PATCH V2 0/3] Introduce TdProtocol into EDK2

Min Xu
 

On October 12, 2021 11:27 PM, Sami Mujawar wrote:
Hi Min,

Thank you for this patch.

I think it would greatly help if the EFI_TD_PROTOCOL is changed to something
more architecture neutral. As I understand, this patch series is removing the
dependency on TPM for measurement and is instead providing a lightweight
interface for extending measurements for Confidential Compute Architecture
(CCA) guests.

Considering this, it would be good to generalise EFI_TD_PROTOCOL as a
Confidential Compute Architecture Measurement (CCAM) protocol.
In fact, your v2 series demonstrates this need with the introduction of
MEASURE_BOOT_PROTOCOLS in "[PATCH V2 2/3] SecurityPkg: Support
TdProtocol in DxeTpm2MeasureBootLib
[https://edk2.groups.io/g/devel/message/81651]".

As it stands, I feel most of the code can be reused/common. Some interfaces
may need to use an architecture specific library, and some configuration
options would need to be defined using PCDs.

Kindly let me know your thoughts.
Thanks for your comments. Let me first discuss your feedback with our architecture. We will reply to your proposal a bit later.

Thanks.
Min
Re: [PATCH V2 06/28] MdePkg: Update BaseIoLibIntrinsicSev to support Tdx

Gerd Hoffmann
 

Hi,

Calling CPUID should not be needed, we have a new fancy
ConfidentialComputing PCD for that now.
The gUefiCpuPkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr is defined in UefiCpuPkg. While BaseIoLibIntrinsicSev is in MdePkg.
If the ConfidentialComputing PCD is used, then UefiCpuPkg has to be included in BaseIoLibIntrinsicSev.inf.
I check all the *.inf under MdePkg but no one *.inf include UefiCpuPkg.
I am not sure if UefiCpuPkg can be included in BaseIoLibIntrinsicSev.inf.
Hmm, I guess we should move the pcd then so it cam be used more widely.
Confidential computing has an impact beyond just cpu, it's also memory,
io and more.

Maybe that's something to cleanup for amd (Brijesh?) beforehand, so the
structure is there already and the tdx patches just need to add the "case tdx:"
bits.
Tdx patches can first use above structure. AMD can update it later. Either way is ok.
That'll work too, I don't care much about the ordering.

take care,
Gerd
Re: [PATCH V2 05/28] MdePkg: Add TdxLib to wrap Tdx operations

Gerd Hoffmann
 

Hi,

+UINT8 *mExtendBufferAddress = NULL;
+TDX_EXTEND_BUFFER mExtendBuffer;
+
+/**
+ TD.RTMR.EXTEND requires 64B-aligned guest physical address of
+ 48B-extension data. In runtime we walk thru the Buffer to find
+ out a 64B-aligned start address.
Can't you just use __attribute__((aligned(64))) for that?
In the PoC of TDVF I had thought about it. But at last I gave up such solution. The reasons are:
1) OVMF/TDVF supports both GCC and VS2019 tool chain. __attribute__((aligned(64))) is for GCC. Its counterpart of VS2019 Tool chain is __declspec(align(x)).
2) There is the limitation of /ALIGN:32 in the build scripts which means aligned 64 exceeds the /ALIGN 32, unless /ALIGN is updated to 64.
That's why the current solution is used.
MdePkg/Include/Base.h has a bunch of ALIGN_* macros to do the math for
you, which should simplify this alot. I'd suggest to also drop the
mExtendBufferAddress and the function calculating it. Just use the
macro instead when needed.

take care,
Gerd
Re: [PATCH V2 28/28] OvmfPkg: Add LocalApicTimerDxe

Min Xu
 

On October 12, 2021 9:02 PM, Gerd Hoffmann wrote:
On Tue, Oct 05, 2021 at 11:39:39AM +0800, Min Xu wrote:
RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429

TDX guest supports LocalApicTimer. But in current OvmfPkg the
supported timer is 8254TimerDxe. So
gUefiOvmfPkgTokenSpaceGuid.PcdTimerSelector
is introduced to select the running Timer. The Timer driver will check
the TimerSelector in its entry point. The default Timer is 8254.
Hmm.

We already have a local apic timer implementation (XenTimerDxe). Works fine
with kvm, microvm already uses that. See commit 76602f45dcd9
("OvmfPkg/Microvm: use XenTimerDxe (lapic timer)").

So, first I'd suggest to just use that (maybe rename the thing to avoid confusion
as it isn't really Xen specific).
Thanks for reminder. Let me first do some more investigation about the XenTimerDxe. It will be better to use an existing lapic timer than introducing a new one.

Next question is whenever there is a need for a runtime switch. I doubt it is
possible to create a virtual machine without lapic, so switching ovmf from 8254
(aka pit) to lapic unconditionally should work fine.
Quick smoke test (patch below) shows no obvious problems.
Let me do some more investigation.
Thanks.
Min
Re: [PATCH] OvmfPkg/Bhyve: Use QemuFwCfg over BhyveFwCtl

Gerd Hoffmann
 

On Wed, Oct 13, 2021 at 11:26:23AM +0200, Corvin Köhne wrote:
From: Corvin Köhne <CorvinK@...>

QemuFwCfg is more powerful and has more use cases than BhyveFwCtl. Try
to use QemuFwCfg in first place. If that fails, fall back to
BhyveFwCtl.
Does bhyve implement the qemu fwcfg interface?

Acked-by: Gerd Hoffmann <kraxel@...>

take care,
Gerd
Re: [PATCH] OvmfPkg/BhyveBhfPkg: install bhyve's ACPI tables

Gerd Hoffmann
 

Hi,

+#define BHYVE_ACPI_PHYSICAL_ADDRESS ((UINTN)0x000F2400)
+#define BHYVE_BIOS_PHYSICAL_END ((UINTN)0x00100000)
+ //
+ // Detect the RSDP
+ //
+ for (RsdpAddress = BHYVE_ACPI_PHYSICAL_ADDRESS;
+ RsdpAddress < BHYVE_BIOS_PHYSICAL_END;
+ RsdpAddress += 0x10) {
+ Rsdp = NUMERIC_VALUE_AS_POINTER (
+ EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER,
+ RsdpAddress
+ );
+ if (Rsdp->Signature != EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER_SIGNATURE) {
+ continue;
+ }
So bhyve copies the tables to guest memory and ovmf searches for them,
correct?

The commit message should (briefly) describe how the tables are passed
from the host to the guest.

The code looks sane to me, so with a more verbose commit message:
Acked-by: Gerd Hoffmann <kraxel@...>

take care,
Gerd
Re: [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Rebecca Cran <rebecca@...>
 

Pushed as 2ebe49ccd34cfd59bac32216b71334d371b3fa44.

Sorry, I forgot to add my "Acked-by" to the commit before pushing.


Acked-by: Rebecca Cran <rebecca@...>

On 10/13/21 10:48 PM, Jayaprakash Nevara wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3638

This change is to add IA32 support into py3 EFI package
creation batch script. Enhanced the script take Architecture
as an additional parameter. With this the script can be used
to create deployable Python 3.6.8 EFI package from X64 and IA32 builds
as required by the user

Cc: Rebecca Cran <rebecca@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Signed-off-by: Jayaprakash N <n.jayaprakash@...>
---
.../Python-3.6.8/create_python368_pkg.bat | 62 ++++++++++++-------
1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
index 6bbdbd9..b48f83e 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
+++ b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
@@ -2,47 +2,63 @@
set TOOL_CHAIN_TAG=%1
set TARGET=%2
-set OUT_FOLDER=%3
+set ARCH=%3
+set OUT_FOLDER=%4
if "%TOOL_CHAIN_TAG%"=="" goto usage
if "%TARGET%"=="" goto usage
+if "%ARCH%"=="" goto usage
if "%OUT_FOLDER%"=="" goto usage
goto continue
:usage
echo.
+echo Batch Script to create Python EFI Package.
echo.
+echo Invalid command line arguments passed, please see the below usage instructions
echo.
-echo Creates Python EFI Package.
-echo.
-echo "Usage: %0 <ToolChain> <Target> <OutFolder>"
-echo.
-echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
-echo Target = one of RELEASE, DEBUG
-echo OutFolder = Target folder where package needs to create
-echo.
+echo "Usage: %0 <ToolChain> <Target> <Architecture> <OutFolder>"
echo.
+echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
+echo Target = one of RELEASE, DEBUG
+echo Architecture = one of IA32, X64
+echo OutFolder = Output directory for creating the package
echo.
goto :eof
:continue
cd ..\..\..\..\
-IF NOT EXIST Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi goto error
-mkdir %OUT_FOLDER%\EFI\Tools
-xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y
-mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
-mkdir %OUT_FOLDER%\EFI\StdLib\etc
-xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
-xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
-goto all_done
-
-:error
-echo Failed to Create Python 3.6.8 Package, Python368.efi is not available on build location Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\
+if not exist Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi (
+ goto error
+)
+if not exist %OUT_FOLDER%\EFI\Tools (
+ mkdir %OUT_FOLDER%\EFI\Tools
+)
+xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y
-:all_done
-exit /b %ec%
-
+if not exist %OUT_FOLDER%\EFI\StdLib\lib\python36.8 (
+ mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
+)
+if not exist %OUT_FOLDER%\EFI\StdLib\etc (
+ mkdir %OUT_FOLDER%\EFI\StdLib\etc
+)
+xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
+xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
+echo.
+if not x%OUT_FOLDER::=%==x%OUT_FOLDER% (
+ echo Python EFI package available at %OUT_FOLDER%
+) else (
+ echo Python EFI package available at %CD%\%OUT_FOLDER%
+)
+goto all_done
+:error
+echo Failed to Create Python EFI Package
+echo Python368.efi is not available at Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\
+echo Follow the instructions in Py368ReadMe.txt to build Python interpreter
+echo Then use this script to create a Python EFI package
+:all_done
+exit /b %ERRORLEVEL%
Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal

Ashish Singhal
 

Hello Jeff,

Thanks for the reference you provided of the change made by you. Leveraging a similar change resolves the problem 90 percent for me as I do not get the ISR interrupted for the most part because of another timer interrupt. However, even with your change, during the ISR there are few instructions during which IRQ is enabled and we may be interrupted by a timer interrupt during that time unless I am understanding it wrong.

Thanks
Ashish
From: fanjianfeng@... <fanjianfeng@...>
Sent: Tuesday, October 12, 2021 8:32 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Ashish Singhal <ashishsingha@...>; Marc Zyngier <maz@...>; Ard Biesheuvel <ardb@...>; Shanker Donthineni <sdonthineni@...>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Leif Lindholm <leif@...>
Subject: Re: Re: [edk2-devel] [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
 
External email: Use caution opening links or attachments

OVMF did a similare change on Time Driver, please refer to https://github.com/tianocore/edk2/commit/239b50a863704f7960525799eda82de061c7c458 

I do not think this will be apply for ArmPkg/TimerDxe. 

If one real issue happened on platform, it seems that interrupt was reenabled by reigstered timer event functions.

Jeff

 
Date: 2021-10-12 23:38
Subject: Re: [edk2-devel] [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
+ Shaker

Get Outlook for iOS
From: Ashish Singhal <ashishsingha@...>
Sent: Tuesday, October 12, 2021 8:56:58 AM
To: Marc Zyngier <maz@...>; Ard Biesheuvel <ardb@...>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@...>; Ard Biesheuvel <ardb+tianocore@...>
Subject: Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
 
Marc,

In the document ARM062-1010708621-30 (AArch64 Programmer's Guides Generic Timer), towards the end of section 3.4 it says: "When writing an interrupt handler for the timers, it is important that software clears the interrupt before deactivating the interrupt in the GIC. Otherwise, the GIC will re-signal the same interrupt again."

My change was in accordance with this. We only clear the interrupt when we update the compare value but were signaling EOI before that going against the guidance in the document.

Thanks
Ashish
From: Marc Zyngier <maz@...>
Sent: Tuesday, October 12, 2021 2:57 AM
To: Ard Biesheuvel <ardb@...>; Ashish Singhal <ashishsingha@...>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@...>; Ard Biesheuvel <ardb+tianocore@...>
Subject: Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
 
External email: Use caution opening links or attachments


On Mon, 11 Oct 2021 23:24:38 +0100,
Ard Biesheuvel <ardb@...> wrote:
>
> (+ Marc)
>
> On Mon, 11 Oct 2021 at 23:40, Ashish Singhal <ashishsingha@...> wrote:
> >
> > In an interrupt handler for the timers, it is important that
> > software clears the interrupt before deactivating the interrupt
> > in the GIC. Otherwise the GIC will re-signal the same interrupt
> > again.
> >
> > Signed-off-by: Ashish Singhal <ashishsingha@...>
>
> Please don't spam us with almost identical versions of the same patch
> without even documenting what the difference is.
>
>
> > ---
> >  ArmPkg/Drivers/TimerDxe/TimerDxe.c | 9 +++++----
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> > index 0370620fae..46e5bbf287 100644
> > --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> > +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> > @@ -300,10 +300,6 @@ TimerInterruptHandler (
> >    //
> >    OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
> >
> > -  // Signal end of interrupt early to help avoid losing subsequent ticks
> > -  // from long duration handlers
> > -  gInterrupt->EndOfInterrupt (gInterrupt, Source);
> > -
> >    // Check if the timer interrupt is active
> >    if ((ArmGenericTimerGetTimerCtrlReg () ) & ARM_ARCH_TIMER_ISTATUS) {
> >
> > @@ -335,6 +331,11 @@ TimerInterruptHandler (
> >      ArmInstructionSynchronizationBarrier ();
> >    }
> >
> > +  // In an interrupt handler for the timers, it is important that software clears the interrupt
> > +  // before deactivating the interrupt in the GIC. Otherwise the GIC will re-signal the same
> > +  // interrupt again.
> > +  gInterrupt->EndOfInterrupt (gInterrupt, Source);
> > +
> >    gBS->RestoreTPL (OriginalTPL);
> >  }
> >

This isn't a requirement if you haven't re-enabled interrupts in
PSTATE (and the TPL being raised seems to indicate that interrupts are
actively masked here).

The timer is a level interrupt, and lowering the level takes time. If
your GIC implementation is good, it will notice that the lowering of
the level quickly, before you can reach the point where you re-enable
interrupts. If it is slow (or badly emulated if this is actually done
in a hypervisor), you'll get a spurious interrupt.

In any case, moving the EOI around doesn't make things any better. You
are just moving the goal post, without additional guarantees that the
level has been retired.

As a consequence, I don't think this patch makes much sense.

        M.

--
Without deviation from the norm, progress is not possible.
[edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Jayaprakash, N
 

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

This change is to add IA32 support into py3 EFI package
creation batch script. Enhanced the script take Architecture
as an additional parameter. With this the script can be used
to create deployable Python 3.6.8 EFI package from X64 and IA32 builds
as required by the user

Cc: Rebecca Cran <rebecca@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Signed-off-by: Jayaprakash N <n.jayaprakash@...>
---
.../Python-3.6.8/create_python368_pkg.bat | 62 ++++++++++++-------
1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
index 6bbdbd9..b48f83e 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
+++ b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
@@ -2,47 +2,63 @@

set TOOL_CHAIN_TAG=%1
set TARGET=%2
-set OUT_FOLDER=%3
+set ARCH=%3
+set OUT_FOLDER=%4
if "%TOOL_CHAIN_TAG%"=="" goto usage
if "%TARGET%"=="" goto usage
+if "%ARCH%"=="" goto usage
if "%OUT_FOLDER%"=="" goto usage
goto continue

:usage
echo.
+echo Batch Script to create Python EFI Package.
echo.
+echo Invalid command line arguments passed, please see the below usage instructions
echo.
-echo Creates Python EFI Package.
-echo.
-echo "Usage: %0 <ToolChain> <Target> <OutFolder>"
-echo.
-echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
-echo Target = one of RELEASE, DEBUG
-echo OutFolder = Target folder where package needs to create
-echo.
+echo "Usage: %0 <ToolChain> <Target> <Architecture> <OutFolder>"
echo.
+echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
+echo Target = one of RELEASE, DEBUG
+echo Architecture = one of IA32, X64
+echo OutFolder = Output directory for creating the package
echo.

goto :eof

:continue
cd ..\..\..\..\
-IF NOT EXIST Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi goto error
-mkdir %OUT_FOLDER%\EFI\Tools
-xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y
-mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
-mkdir %OUT_FOLDER%\EFI\StdLib\etc
-xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
-xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
-goto all_done
-
-:error
-echo Failed to Create Python 3.6.8 Package, Python368.efi is not available on build location Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\
+if not exist Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi (
+ goto error
+)

+if not exist %OUT_FOLDER%\EFI\Tools (
+ mkdir %OUT_FOLDER%\EFI\Tools
+)
+xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y

-:all_done
-exit /b %ec%
-
+if not exist %OUT_FOLDER%\EFI\StdLib\lib\python36.8 (
+ mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
+)
+if not exist %OUT_FOLDER%\EFI\StdLib\etc (
+ mkdir %OUT_FOLDER%\EFI\StdLib\etc
+)
+xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
+xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
+echo.

+if not x%OUT_FOLDER::=%==x%OUT_FOLDER% (
+ echo Python EFI package available at %OUT_FOLDER%
+) else (
+ echo Python EFI package available at %CD%\%OUT_FOLDER%
+)
+goto all_done

+:error
+echo Failed to Create Python EFI Package
+echo Python368.efi is not available at Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\
+echo Follow the instructions in Py368ReadMe.txt to build Python interpreter
+echo Then use this script to create a Python EFI package

+:all_done
+exit /b %ERRORLEVEL%
--
2.32.0.windows.2
[edk2-libc Patch v2 0/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Jayaprakash, N
 

Jayaprakash Nevara (1):
AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3
package creation batch script

.../Python-3.6.8/create_python368_pkg.bat | 62 ++++++++++++-------
1 file changed, 39 insertions(+), 23 deletions(-)
TianoCore Community Meeting Minutes - October 2021

Soumya Guptha
 

TianoCore Community Meeting

October 7, 2021

 

Events

UEFI Plugfest:

No new updates since last month.

Past AR review from September –

o       Community Action: provide input to Dick Wilkins Dick_Wilkins@...<mailto:Dick_Wilkins@...> on these questions -

*       Is your company interested in sponsoring?

*       Are you willing to pay for the conference?

 

Community Response - Community thinks that it’s useful to have a face to face event.

Paying for the conference maybe fine for those that need to pay for hotel and flight.

Aligning with UEFI plugfest is beneficial for the TianoCore design/technical roadmap discussions and for the TianoCore community to come together. 

 

 

Stable Tag updates:

Stable tag 202111 is collecting features.

Soft freeze on Nov 8th.

Community Action: please send your feature requests ahead of time to Liming.

 

 

Stewards Download:

  1. Inclusive language: Stewards discussed TianoCore to follow inclusive language and layout the guidelines. Community manager will drive further conversations with stewards and community in the upcoming weeks.
  2. Discussion around Uncrustify tool.  

Reduces code review time and provides consistent code base when having to recode so you don’t see mixed styles in diff parts of the tree.

Community action – review the code style and provide feedback if you like it or not and what changes would you like to see.

EDK2 C coding style is not identical to Uncrustify. Should we change EDK2 style?

Please follow the discussion here - https://edk2.groups.io/g/devel/topic/progress_on_getting/84932137?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,84932137,previd=1633659901428425771,nextid=1633620778663080075&previd=1633659901428425771&nextid=1633620778663080075

  1. Felix had sent RFC on static analysis on EDK2 but no feedback from the community. Community to send feedback to Felix.

Please follow the discussion here - https://edk2.groups.io/g/rfc/topic/rfc_static_analysis_in_edk2/85318202?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,85318202,previd=1633604560724866953,nextid=1619704994055247213&previd=1633604560724866953&nextid=1619704994055247213

  1. Spam on Bugzilla (Mike Kinney) – we need to change the configuration of TianoCore Bugzilla. We have been handling so far by disabling those spammers and these emails remain in our mailing list.

a.       Mike has handled it by changing the permissions disabling for people to create accounts to avoid the spam. 

Open: What process should we follow?

AR: Mike and Liming will follow up in the email on the TianoCore Bugzilla account creation process and post it. wiki pages need to be updated as well.

 

Opens:

  1. Update from Soumya Guptha: Lynn Teng from Intel will be acting as Community manager and picking up community management responsibilities starting this month. Please extend your support to Lynn Teng. Soumya Guptha will be stepping away from the Community management during this time.
  2. Update from Nate Desimone –Intel® Xeon Scalable Processors, Ice Lake and Cooper Lake min platform has been released.
  3. OCP Global Summit: Scheduled on Nov 9-10, 2021. This year is a hybrid model – both in-person and online, held in San Jose, California, US.

OCP summit schedule here - https://2021ocpglobal.fnvirtual.app/a/schedule

Check out these sessions –

1)      Wed, November 10, 2:15pm - 2:30pm | SJCC - Concourse Level - 210BF FSP and MinPlatform for Sapphire Rapids Intel® Xeon® Scalable Processors by Nate Desimone and Isaac Oram (Intel).

2)      Wed, November 10, 4:15pm - 4:30pm | SJCC - Concourse Level - 210BF Enabling Runtime RAS on Xeon OCP Platforms Using Intel FSP and Coreboot by Ruth Li

 

 

Regards,

Soumya Guptha

TianoCore Community Manager

 
Re: [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Rebecca Cran <rebecca@...>
 

Sorry for the delay.

I can't see the copy of the patch you sent out: could you send it again, this time marking it as v2 please? Since it's sent out via email there's no problem with duplicates.


--

Rebecca Cran

On 10/3/21 6:35 PM, Jayaprakash, N wrote:
Hi Rebecca / Mike,

Could you look into this?

Regards,
JP

-----Original Message-----
From: Jayaprakash, N
Sent: 24 September 2021 13:34
To: devel@edk2.groups.io; rebecca@...
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Apologies, I have already shared the patch.
I will take this input for future patches.

Regards,
JP

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
Sent: 24 September 2021 00:02
To: Jayaprakash, N <n.jayaprakash@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Sorry I don't see it. Could you re-send it with "PATCH v2" in the subject line (by passing -v2 to "git format-patch") if you didn't already please?


--
Rebecca Cran


On 9/22/21 10:22 PM, Jayaprakash, N wrote:
Thank you Rebecca.
I have submitted the updated patch for review.

Regards,
JP

-----Original Message-----
From: Rebecca Cran <rebecca@...>
Sent: 23 September 2021 06:59
To: Jayaprakash, N <n.jayaprakash@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

You should be able to use the same branch.
[PATCH v1 1/1] StandaloneMmPkg: To support CLANGPDB build

Jiyang Yang
 

the flag "-fpie" is passed for all builds with a GCC family toolchain,
including CLANGPDB, but CLANGPDB does not support this flag, it will
report "clang: error: unsupported option '-fpie' for target
'x86_64-unknown-windows-gnu'". So we add the CLANGPDB option "-fno-pie"
later to overwrite it.

Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>
Cc: Vitaly Cheptsov <vit9696@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Steven Shi <steven.shi@...>
Signed-off-by: Jiyang Yang <jiyangx.yang@...>
---
StandaloneMmPkg/Core/StandaloneMmCore.inf | 2 ++
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 1 +
2 files changed, 3 insertions(+)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index 56042b7b39f4..3213142523f4 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -79,3 +79,5 @@
[BuildOptions]
GCC:*_*_*_CC_FLAGS = -fpie
GCC:*_*_*_DLINK_FLAGS = -Wl,-z,text,-Bsymbolic,-pie
+ CLANGPDB:*_*_*_CC_FLAGS = -fno-pie
+ CLANGPDB:*_*_*_DLINK_FLAGS =
diff --git a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
index 1762586cfa02..ef69e07d2c07 100644
--- a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
+++ b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
@@ -56,3 +56,4 @@

[BuildOptions]
GCC:*_*_*_CC_FLAGS = -fpie
+ CLANGPDB:*_*_*_CC_FLAGS = -fno-pie
--
2.26.2.windows.1
[PATCH v1 0/1] StandaloneMmPkg: To support CLANGPDB build

Jiyang Yang
 

the flag "-fpie" is passed for all builds with a GCC family toolchain,
including CLANGPDB, but CLANGPDB does not support this flag, it will
report "clang: error: unsupported option '-fpie' for target
'x86_64-unknown-windows-gnu'". So we add the CLANGPDB option "-fno-pie"
later to overwrite it.

Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>
Cc: Vitaly Cheptsov <vit9696@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Steven Shi <steven.shi@...>
Signed-off-by: Jiyang Yang <jiyangx.yang@...>

Jiyang Yang (1):
StandaloneMmPkg/StandaloneMmCoreEntryPoint: To support CLANGPDB build

StandaloneMmPkg/Core/StandaloneMmCore.inf | 2 ++
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 1 +
2 files changed, 3 insertions(+)


--
2.26.2.windows.1
Re: [PATCH v3] MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleList

Dandan Bi
 

Reviewed-by: Dandan Bi <dandan.bi@...>



Thanks,
Dandan

-----Original Message-----
From: Wang, Jian J <jian.j.wang@...>
Sent: Wednesday, October 13, 2021 4:11 PM
To: Ma, Hua <hua.ma@...>; devel@edk2.groups.io
Cc: Liming Gao <gaoliming@...>; Bi, Dandan
<dandan.bi@...>; Ni, Ray <ray.ni@...>
Subject: RE: [PATCH v3] MdeModulePkg/Core/Dxe: Acquire a lock when
iterating gHandleList

Reviewed-by: Jian J Wang <jian.j.wang@...>

Regards,
Jian

-----Original Message-----
From: Ma, Hua <hua.ma@...>
Sent: Wednesday, October 13, 2021 3:45 PM
To: devel@edk2.groups.io
Cc: Ma, Hua <hua.ma@...>; Wang, Jian J <jian.j.wang@...>;
Liming Gao <gaoliming@...>; Bi, Dandan
<dandan.bi@...>; Ni, Ray <ray.ni@...>
Subject: [PATCH v3] MdeModulePkg/Core/Dxe: Acquire a lock when
iterating gHandleList

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

This patch fixes the following issue:

The global variable gHandleList is a linked list.
This list is locked when a entry is added or removed from the list,
but there is no lock when iterating this list in function
CoreValidateHandle().
It can lead to "Handle.c (76): CR has Bad Signature" assertion if the
iterated entry in the list is just removed by other task during iterating.

Currently some caller functions of CoreValidateHandle() have
CoreAcquireProtocolLock(), but some caller functions of
CoreValidateHandle() do not CoreAcquireProtocolLock().
Add CoreAcquireProtocolLock() always when CoreValidateHandle() is
called, Also, A lock check is added in the CoreValidateHandle().

v3 changes:
- keep ASSERT_LOCKED(&gProtocolDatabaseLock) in CoreValidateHandle()
- Call CoreAcquireProtocolLock() before any calling of
CoreValidateHandle() and CoreReleaseProtocolLock() afterwards
- Update the commit message

v2 changes:
- Add lock check and comments in CoreGetProtocolInterface() before
calling CoreValidateHandle()
- Update the comments in CoreValidateHandle() header file

v1: https://edk2.groups.io/g/devel/topic/86233569

Cc: Jian J Wang <jian.j.wang@...>
Cc: Liming Gao <gaoliming@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: Ray Ni <ray.ni@...>
Signed-off-by: Hua Ma <hua.ma@...>
---
MdeModulePkg/Core/Dxe/Hand/DriverSupport.c | 16 +++++
MdeModulePkg/Core/Dxe/Hand/Handle.c | 75 ++++++++++++----------
MdeModulePkg/Core/Dxe/Hand/Handle.h | 1 +
MdeModulePkg/Core/Dxe/Hand/Notify.c | 13 ++--
4 files changed, 64 insertions(+), 41 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
b/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
index feabf12faf..12a202417c 100644
--- a/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
+++ b/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
@@ -68,7 +68,12 @@ CoreConnectController (
//
// Make sure ControllerHandle is valid
//
+ CoreAcquireProtocolLock ();
+
Status = CoreValidateHandle (ControllerHandle);
+
+ CoreReleaseProtocolLock ();
+
if (EFI_ERROR (Status)) {
return Status;
}
@@ -268,7 +273,12 @@ AddSortedDriverBindingProtocol (
//
// Make sure the DriverBindingHandle is valid
//
+ CoreAcquireProtocolLock ();
+
Status = CoreValidateHandle (DriverBindingHandle);
+
+ CoreReleaseProtocolLock ();
+
if (EFI_ERROR (Status)) {
return;
}
@@ -746,8 +756,11 @@ CoreDisconnectController (
//
// Make sure ControllerHandle is valid
//
+ CoreAcquireProtocolLock ();
+
Status = CoreValidateHandle (ControllerHandle);
if (EFI_ERROR (Status)) {
+ CoreReleaseProtocolLock ();
return Status;
}

@@ -757,10 +770,13 @@ CoreDisconnectController (
if (ChildHandle != NULL) {
Status = CoreValidateHandle (ChildHandle);
if (EFI_ERROR (Status)) {
+ CoreReleaseProtocolLock ();
return Status;
}
}

+ CoreReleaseProtocolLock ();
+
Handle = ControllerHandle;

//
diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.c
b/MdeModulePkg/Core/Dxe/Hand/Handle.c
index 6eccb41ecb..92979281b7 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Handle.c
+++ b/MdeModulePkg/Core/Dxe/Hand/Handle.c
@@ -53,6 +53,7 @@ CoreReleaseProtocolLock (

/**
Check whether a handle is a valid EFI_HANDLE
+ The gProtocolDatabaseLock must be owned

@param UserHandle The handle to check

@@ -72,6 +73,8 @@ CoreValidateHandle (
return EFI_INVALID_PARAMETER;
}

+ ASSERT_LOCKED(&gProtocolDatabaseLock);
+
for (Link = gHandleList.BackLink; Link != &gHandleList; Link = Link->BackLink)
{
Handle = CR (Link, IHANDLE, AllHandles, EFI_HANDLE_SIGNATURE);
if (Handle == (IHANDLE *) UserHandle) { @@ -720,19 +723,19 @@
CoreUninstallProtocolInterface (
return EFI_INVALID_PARAMETER;
}

+ //
+ // Lock the protocol database
+ //
+ CoreAcquireProtocolLock ();
+
//
// Check that UserHandle is a valid handle
//
Status = CoreValidateHandle (UserHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}

- //
- // Lock the protocol database
- //
- CoreAcquireProtocolLock ();
-
//
// Check that Protocol exists on UserHandle, and Interface matches
the interface in the database
//
@@ -1010,12 +1013,17 @@ CoreOpenProtocol (
return EFI_INVALID_PARAMETER;
}

+ //
+ // Lock the protocol database
+ //
+ CoreAcquireProtocolLock ();
+
//
// Check for invalid UserHandle
//
Status = CoreValidateHandle (UserHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}

//
@@ -1025,31 +1033,32 @@ CoreOpenProtocol (
case EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER :
Status = CoreValidateHandle (ImageHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
Status = CoreValidateHandle (ControllerHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
if (UserHandle == ControllerHandle) {
- return EFI_INVALID_PARAMETER;
+ Status = EFI_INVALID_PARAMETER;
+ goto Done;
}
break;
case EFI_OPEN_PROTOCOL_BY_DRIVER :
case EFI_OPEN_PROTOCOL_BY_DRIVER |
EFI_OPEN_PROTOCOL_EXCLUSIVE :
Status = CoreValidateHandle (ImageHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
Status = CoreValidateHandle (ControllerHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
break;
case EFI_OPEN_PROTOCOL_EXCLUSIVE :
Status = CoreValidateHandle (ImageHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
break;
case EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL :
@@ -1057,13 +1066,10 @@ CoreOpenProtocol (
case EFI_OPEN_PROTOCOL_TEST_PROTOCOL :
break;
default:
- return EFI_INVALID_PARAMETER;
+ Status = EFI_INVALID_PARAMETER;
+ goto Done;
}

- //
- // Lock the protocol database
- //
- CoreAcquireProtocolLock ();

//
// Look at each protocol interface for a match @@ -1246,32 +1252,33
@@ CoreCloseProtocol (
LIST_ENTRY *Link;
OPEN_PROTOCOL_DATA *OpenData;

+ //
+ // Lock the protocol database
+ //
+ CoreAcquireProtocolLock ();
+
//
// Check for invalid parameters
//
Status = CoreValidateHandle (UserHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
Status = CoreValidateHandle (AgentHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
if (ControllerHandle != NULL) {
Status = CoreValidateHandle (ControllerHandle);
if (EFI_ERROR (Status)) {
- return Status;
+ goto Done;
}
}
if (Protocol == NULL) {
- return EFI_INVALID_PARAMETER;
+ Status = EFI_INVALID_PARAMETER;
+ goto Done;
}

- //
- // Lock the protocol database
- //
- CoreAcquireProtocolLock ();
-
//
// Look at each protocol interface for a match
//
@@ -1443,13 +1450,6 @@ CoreProtocolsPerHandle (
UINTN ProtocolCount;
EFI_GUID **Buffer;

- Status = CoreValidateHandle (UserHandle);
- if (EFI_ERROR (Status)) {
- return Status;
- }
-
- Handle = (IHANDLE *)UserHandle;
-
if (ProtocolBuffer == NULL) {
return EFI_INVALID_PARAMETER;
}
@@ -1464,6 +1464,13 @@ CoreProtocolsPerHandle (

CoreAcquireProtocolLock ();

+ Status = CoreValidateHandle (UserHandle); if (EFI_ERROR (Status))
+ {
+ goto Done;
+ }
+
+ Handle = (IHANDLE *)UserHandle;
+
for (Link = Handle->Protocols.ForwardLink; Link !=
&Handle->Protocols; Link =
Link->ForwardLink) {
ProtocolCount++;
}
diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h
b/MdeModulePkg/Core/Dxe/Hand/Handle.h
index 83eb2b9f3a..3f83e3af15 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
+++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
@@ -242,6 +242,7 @@ CoreReleaseProtocolLock (

/**
Check whether a handle is a valid EFI_HANDLE
+ The gProtocolDatabaseLock must be owned

@param UserHandle The handle to check

diff --git a/MdeModulePkg/Core/Dxe/Hand/Notify.c
b/MdeModulePkg/Core/Dxe/Hand/Notify.c
index 553413a350..d05f95207f 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Notify.c
+++ b/MdeModulePkg/Core/Dxe/Hand/Notify.c
@@ -188,22 +188,21 @@ CoreReinstallProtocolInterface (
PROTOCOL_INTERFACE *Prot;
PROTOCOL_ENTRY *ProtEntry;

- Status = CoreValidateHandle (UserHandle);
- if (EFI_ERROR (Status)) {
- return Status;
- }
-
if (Protocol == NULL) {
return EFI_INVALID_PARAMETER;
}

- Handle = (IHANDLE *) UserHandle;
-
//
// Lock the protocol database
//
CoreAcquireProtocolLock ();

+ Status = CoreValidateHandle (UserHandle); if (EFI_ERROR (Status))
+ {
+ goto Done;
+ }
+
+ Handle = (IHANDLE *) UserHandle;
//
// Check that Protocol exists on UserHandle, and Interface matches
the interface in the database
//
--
2.32.0.windows.2
Re: [PATCH V2 27/28] OvmfPkg: Update IoMmuDxe to support TDX

Min Xu
 

On October 12, 2021 8:16 PM, Gerd Hoffmann wrote:
Hi,

+#define IO_MMU_LEGACY 0x0
+#define IO_MMU_SEV 0x01
+#define IO_MMU_TDX 0x02
+
+UINTN mIoMmuType = IO_MMU_LEGACY;
Yet another place where you should be able to just use the
ConfidentialComputing PCD.
Thanks for reminder. It will be updated in next version.

Thanks
Min
Re: [PATCH V9 2/4] OvmfPkg: Clear WORK_AREA_GUEST_TYPE in Main.asm

Min Xu
 

On October 13, 2021 11:46 PM, Brijesh Singh wrote:
On 10/12/21 5:58 PM, Xu, Min M wrote:
On October 12, 2021 9:23 PM, Lendacky Thomas wrote:
Good point Tom. The WORK_AREA_GUEST_TYPE define should be moved
outside the ARCH_X86. I missed it mainly because we renamed the
ESWorkArea to Generic workarea but EsWorkArea was defined in ARCH_X86
only.

Min,

I can send a patch to move define outside the ARCH_X64 and then you can
align the TDX code accordingly.
Ok. I will update the TDX code based on your new patch.

Thanks.
Min
Re: [PATCH V2 14/28] OvmfPkg: Update SecEntry.nasm to support Tdx

Min Xu
 

On October 12, 2021 6:39 PM, Gerd Hoffmann wrote:
Hi,

- AcceptPages:
To mitigate the performance impact of accepting pages in SEC phase on
BSP, BSP will parse memory resources and assign each AP the task of
accepting a subset of pages. This command may be called several times
until all memory resources are processed. In accepting pages, PageLevel
may fall back to smaller one if SIZE_MISMATCH error is returned.
Hmm, I'm wondering whenever it is useful to have this in the first place with
the longer-term plan to implement lazy on-demand acceptance.
To mitigate the performance impact of accepting pages, there are 3 ways.
1. Big accept page size.
2. Accept the pages by BSP and APs together.
3. Lazy on-demand acceptance.
From the perspective of implementation complexity, 1 < 2 < 3.
Lazy on-demand acceptance need the update not only in TDVF, but also in Guest kernel. More investigation shows it also impacts the grub and memory management in EDK2.
From the perspective of performance improvement, 2M accept page size + BSP/AP together, can improve the performance a lot.
Based on above consideration, in current TDVF upstream, 1 + 2 are the ways to mitigate the performance impact.
Upstream of 3 is in the future plan.

Thanks!
Min
Re: [PATCH V2 13/28] UefiCpuPkg: Enable Tdx support in MpInitLib

Min Xu
 

On October 12, 2021 6:32 PM, Gerd Hoffman wrote:
Hi,

+ do {
+ AsmCpuid (0, &LargestEax, &Ebx, &Ecx, &Edx);
Again: this should use PCD.
ConfidentialComputing PCD is set in PlatformPei. So any check of this PCD should be after PlatformPei.
MpInitLib will be included in CpuMpPei. So if PCD is checked in MpInitLib, then we must assume CpuMpPei is called after PlatformPei.
In current OVMF, CpuMpPei is called after PlatforPei. But I am not sure if it is always the case. Can we have such assumption?
Based on above consideration, CPUID is used to probe if it is Tdx guest.

take care,
Gerd
17681 - 17700 of 99549