Re: [edk2-devel] [PATCH] UefiCpuPkg: Use NonSmm BSP as BSP if BSP election is not enabled.

[Laszlo Ersek]

On 11/14/23 17:53, Laszlo Ersek wrote:

> Second, "SMM_DISPATCHER_MP_SYNC_DATA.BspIndex" has type "(volatile)
> UINT32", but WhoAmI() writes an UINTN. On IA32, you're going to corrupt
> memory.

sorry, it's on X64 where you are going to corrupt memory (the UINTN
write is a UINT64 write, but the field to accept it is only UINT32)

Laszlo



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Use NonSmm BSP as BSP if BSP election is not enabled.

[Laszlo Ersek]

Small patch, but I have several comments :)

On 11/14/23 03:08, Zhiguang Liu wrote:
> Currently, if BSP election is not enabled, will use Core0 as SMM BSP,
> however, Core0 does not always have the highest performance core.
> So, we can used NonSmm BSP as default BSP.

(1) Please consider mentioning in the commit message that the change
from this patch will take effect in SmiRendezvous().

(2) Please put "UefiCpuPkg/PiSmmCpuDxeSmm: ..." in the subject.

>
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 10 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 48 +++---
>  2 files changed, 34 insertions(+), 24 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 25d058c5b9..a4f83bb122 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -29,6 +29,8 @@ MM_COMPLETIONmSmmStartupThisApToken;
>  //
>  UINT32  *mPackageFirstThreadIndex = NULL;
>
> +extern EFI_MP_SERVICES_PROTOCOL  *mMpServices;
> +
>  /**
>Performs an atomic compare exchange operation to get semaphore.
>The compare exchange operation must be performed using
> @@ -1953,6 +1955,14 @@ InitializeMpSyncData (
>// Enable BSP election by setting BspIndex to -1
>//
>mSmmMpSyncData->BspIndex = (UINT32)-1;
> +} else {
> +  //
> +  // Use NonSMM BSP as SMM BSP
> +  //
> +  ASSERT (mMpServices != NULL);
> +  if (mMpServices != NULL) {
> +mMpServices->WhoAmI (mMpServices, (UINTN 
> *)>BspIndex);
> +  }
>  }
>
>  mSmmMpSyncData->EffectiveSyncMode = mCpuSmmSyncMode;


(3) This branch cannot be tested on OVMF, due to commit 43df61878d94
("OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmm", 2020-03-04).

That's not a problem with the patch of course, just saying that I can't
offer regression testing.


(4) Not checking the return value of WhoAmI() is actually valid here.
Per PI spec, WhoAmI() can only fail if we pass a null pointer for
"ProcessorNumber" (and we don't do that here).

Not sure about static analysis tools though. If they complain, we might
want to cast the return value to (VOID) explicitly:

  (VOID)mMpServices->WhoAmI (...);

Not needed unless those tools complain, of course.


(5) Passing the following argument for the "ProcessorNumber" parameter

  (UINTN *)>BspIndex

is undefined behavior, for two reasons.

First, "SMM_DISPATCHER_MP_SYNC_DATA.BspIndex" is volatile-qualified, but
the access here (or more precisely, inside WhoAmI()) happens through an
lvalue that doesn't necessarily have volatile-qualified type. That's UB.

Second, "SMM_DISPATCHER_MP_SYNC_DATA.BspIndex" has type "(volatile)
UINT32", but WhoAmI() writes an UINTN. On IA32, you're going to corrupt
memory.

Therefore you should to do this:

  UINTN DxeBspNumber;

  MpServices->WhoAmI (mMpServices, );
  if (DxeBspNumber <= MAX_UINT32) {
mSmmMpSyncData->BspIndex = (UINT32)DxeBspNumber;
  }

In other words, use a local variable of the right type, and range check
it. If the range check fails, then just fall back to the current
behavior (leave BspIndex at zero). Otherwise, employ an explicit
assignment, including casting. This will in particular keep "volatile"
happy (and there can't be any overflow either, after the range check).

One more comment below:

> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index 1d022a7051..18c77c59e6 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -128,7 +128,8 @@ SPIN_LOCK  *mConfigSmmCodeAccessCheckLock = NULL;
>  EFI_SMRAM_DESCRIPTOR  *mSmmCpuSmramRanges;
>  UINTN mSmmCpuSmramRangeCount;
>
> -UINT8  mPhysicalAddressBits;
> +UINT8 mPhysicalAddressBits;
> +EFI_MP_SERVICES_PROTOCOL  *mMpServices;
>
>  //
>  // Control register contents saved for SMM S3 resume state initialization.
> @@ -603,26 +604,25 @@ PiCpuSmmEntry (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> -  EFI_STATUSStatus;
> -  EFI_MP_SERVICES_PROTOCOL  *MpServices;
> -  UINTN NumberOfEnabledProcessors;
> -  UINTN Index;
> -  VOID  *Buffer;
> -  UINTN BufferPages;
> -  UINTN TileCodeSize;
> -  UINTN TileDataSize;
> -  UINTN TileSize;
> -  UINT8 *Stacks;
> -  VOID  *Registration;
> -  UINT32RegEax;
> -  UINT32RegEbx;
> -  UINT32RegEcx;
> -  UINT32RegEdx;
> -  UINTN FamilyId;
> -  UINTN ModelId;
> -  UINT32Cr3;
> -  EFI_HOB_GUID_TYPE *GuidHob;
> -  SMM_BASE_HOB_DATA 

Re: [edk2-devel] [PATCH] MdeModulePkg/Variable: Merge variable header + data update into one step

[Laszlo Ersek]

+Jiewen (I seem to remember Jiewen co-authored a whitepaper on edk2
variables; I could be wrong)

one more comment below:

On 11/14/23 09:23, Gao wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4597
> 
> When creating a new variable, skip marking VAR_HEADER_VALID_ONLY so that
> variable header + data update can be merged into one flash write. This
> will greatly reduce the time taken for updating a variable and thus
> increase performance. Removing VAR_HEADER_VALID_ONLY marking doesn't
> have any function impact since it's not used by current code to detect
> variable header + data corruption.

That would have been my question; thanks for spelling it out in advance
(in the commit message).

I wouldn't like to start reviewing this right now, but if you don't get
a review in a week or so, feel free to ping me; I'll try to dig into it.

Laszlo

> 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Signed-off-by: Gao Cheng 
> ---
>  .../Universal/Variable/RuntimeDxe/Variable.c  | 45 ++-
>  1 file changed, 4 insertions(+), 41 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 7a1331255b..3c360481f4 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -2168,11 +2168,9 @@ UpdateVariable (
>  
>  if (!mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
>//
> -  // Four steps
> -  // 1. Write variable header
> -  // 2. Set variable state to header valid
> -  // 3. Write variable data
> -  // 4. Set variable state to valid
> +  // Two steps
> +  // 1. Write variable header and data
> +  // 2. Set variable state to valid
>//
>//
>// Step 1:
> @@ -2183,7 +2181,7 @@ UpdateVariable (
>   TRUE,
>   Fvb,
>   mVariableModuleGlobal->NonVolatileLastVariableOffset,
> - (UINT32)GetVariableHeaderSize (AuthFormat),
> + (UINT32)VarSize,
>   (UINT8 *)NextVariable
>   );
>  
> @@ -2194,41 +2192,6 @@ UpdateVariable (
>//
>// Step 2:
>//
> -  NextVariable->State = VAR_HEADER_VALID_ONLY;
> -  Status  = UpdateVariableStore (
> -  >VariableGlobal,
> -  FALSE,
> -  TRUE,
> -  Fvb,
> -  
> mVariableModuleGlobal->NonVolatileLastVariableOffset + OFFSET_OF 
> (VARIABLE_HEADER, State),
> -  sizeof (UINT8),
> -  >State
> -  );
> -
> -  if (EFI_ERROR (Status)) {
> -goto Done;
> -  }
> -
> -  //
> -  // Step 3:
> -  //
> -  Status = UpdateVariableStore (
> - >VariableGlobal,
> - FALSE,
> - TRUE,
> - Fvb,
> - mVariableModuleGlobal->NonVolatileLastVariableOffset + 
> GetVariableHeaderSize (AuthFormat),
> - (UINT32)(VarSize - GetVariableHeaderSize (AuthFormat)),
> - (UINT8 *)NextVariable + GetVariableHeaderSize (AuthFormat)
> - );
> -
> -  if (EFI_ERROR (Status)) {
> -goto Done;
> -  }
> -
> -  //
> -  // Step 4:
> -  //
>NextVariable->State = VAR_ADDED;
>Status  = UpdateVariableStore (
>>VariableGlobal,



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

Re: [edk2-devel] edk2 uncrustify update (73.0.8)?

[Laszlo Ersek]

On 11/13/23 22:33, Pedro Falcato wrote:
> On Mon, Nov 13, 2023 at 8:37 PM Rebecca Cran  wrote:
>>
>> On 11/13/2023 1:08 PM, Michael Kubacki wrote:
>>> Yes. I just did it. It is relatively minor and impacts expected code
>>> areas.
>>>
>>> https://github.com/tianocore/edk2/pull/5043/files
>>
>>
>> Could you update .git-blame-ignore-revs please?
> 
> You can't do that until the merge is done, since we use
> rebase-and-merge for tianocore (and rebases do not keep stable commit
> hashes).
> But I would plead that this should not get merged in general :/

Seeing the cumulative diff in that PR, do you have specific
counter-arguments?

The diff is trivial, IMO. You mentioned "error prone" and "much churn",
which are very valid concerns, but they don't seem to apply here. We can
review a diff of this size (especially if it's split up on Pkg
boundaries), and the github view indicates the change is only in
whitespace amount.

The change in
"OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c"
is a net win; the current formatting is really distracting.

Furthermore, this diff actually highlights some inexplicable syntax in
"EmulatorPkg/FvbServicesRuntimeDxe/FvbInfo.c": those backslashes (not
parts of any macro definition) are an eyesore. They should be fixed
regardless of re-uncrustification.

The version N vs. N+1 concern shouldn't be one; the authoritative
version is what the YAML file in edk2 says.

Thanks!
Laszlo



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

Re: [edk2-devel] edk2 uncrustify update (73.0.8)?

[Laszlo Ersek]

On 11/13/23 20:07, Pedro Falcato wrote:
> On Mon, Nov 13, 2023 at 11:58 AM Laszlo Ersek  wrote:
>>
>> Hi Michael,
>>
>> recently I encountered an uncrustify failure on github.
>>
>> The reason was that my local uncrustify was *more recent* (73.0.8) than
>> the one we use in edk2 CI (which is 73.0.3, per the edk2 file
>> ".pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml").
> 
> Wait, you can use upstream uncrustify? I'm just using whatever
> uncrustify version I took from the project-mu fork...

Apologies -- for edk2 purposes (and I don't use uncrustify for anything
else), I consider
<https://projec...@dev.azure.com/projectmu/Uncrustify/_git/Uncrustify>
"upstream".

> 
>>
>> Updating the version number in the YAML file (i.e., advancing edk2 to
>> version 73.0.8) seems easy enough, but:
>>
>> - Do you think 73.0.8 is mature enough for adoption in edk2?
>>
>>   This upstream uncrustify release was tagged in April (and I can't see
>>   any more recent commits), so I assume it should be stable.
>>
>> - Would the version update require a whole-tree re-uncrustification?
> 
> Please, no. I didn't mind doing an initial reformatting at first, but
> doing this continuously is both 1) problem-prone 2) just amazing
> amounts of churn.
> Let's say I have version N, you have version N+1 - we may never get
> any final, formatted output as your version formats it differently
> from mine.

Your argument against a continuously reformatted code base is well
received; just a small correction: we should never have an N vs. N+1
dilemma. What CI uses is the authoritative version.

> 
> I don't know how the CI is doing its thing atm (I haven't merged
> anything myself to edk2), but the uncrustify check should be relaxed
> to just a warning.

I don't think that's going to happen. Everybody ignores warnings when in
a rush, or when the same warnings pop up for the 10th time.

> There's nothing wrong with what my uncrustify
> version is formatting to, there's nothing wrong with yours either, and
> CI isn't necessarily wrong either.
> 
> And, to be fair, I already find uncrustify a large pain in the butt to
> use (requiring a custom fork really does not help), but I find the
> benefits worth it *locally*, as my coding style is also quite
> different from the NT-esque style.

Funnily enough, my stance is quite the opposite. I happen to disagree
with some patterns that uncrustify enforces, but I'm thankful that at
any given state of CI (= using any given version of uncrustify), we
can't have any more debates about patch formatting (that is, it's
especially its central nature that I like). I've found uncrustify
relatively easy to use locally, too.

All in all I'm not trying to upset the status quo, it's just a question
about a version bump, and how we'd deal with any fallout from that.

Laszlo



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

Re: [edk2-devel] [PATCH v4 0/5] UefiCpuPkg: Add macro definitions for CET feature for NASM files.

[Laszlo Ersek]

On 11/13/23 07:22, Sheng Wei wrote:
> Patch V4:
>   Separate the changes to 5 patches.
> 1) Add macro definitions for CET feature for NASM files.
> 2) Use macro CR4_CET_BIT to replace hard code value in Cet.nasm.
> 3) Use CET macro definitions in Cet.inc for SmiEntry.nasm files.
> 4) Only change CR4.CET bit for enable/disable CET.
> 5) Backup and Restore MSR IA32_U_CET in SMI handler.
>   Remove some unused code.
> It is no need to clear MSR IA32_S_CET,
>  because clear CR4.CET bit will disable all CET functions.
> Since CET is disabled between clear CR4.CET and run 'rsm',
>  it is no need to delay MSR IA32_S_CET restoration.
> 
> Patch V3:
>   Remove the 3rd patch. mSmmInterruptSspTables is a global variable.
>   It is unnecessary to initializ it to zero manually.
> 
> Patch V2:
>   No function change with Patch V1.
>   Split the patch to into 3 separate patches.
> 
> Sheng Wei (5):
>   UefiCpuPkg: Add macro definitions for CET feature for NASM files.
>   UefiCpuPkg: Use macro CR4_CET_BIT to replace hard code value in
> Cet.nasm.
>   UefiCpuPkg: Use CET macro definitions in Cet.inc for SmiEntry.nasm
> files.
>   UefiCpuPkg: Only change CR4.CET bit for enable and disable CET.
>   UefiCpuPkg: Backup and Restore MSR IA32_U_CET in SMI handler.
> 
>  UefiCpuPkg/Include/Cet.inc   | 26 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm  |  5 ++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 39 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm   |  5 ++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm  | 40 +++-
>  5 files changed, 78 insertions(+), 37 deletions(-)
>  create mode 100644 UefiCpuPkg/Include/Cet.inc
> 

series
Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [Patch V4] UefiCpuPkg/MpInitLib: Enable execute disable bit.

[Laszlo Ersek]

On 11/13/23 06:59, Yuanhao Xie wrote:
> From: Yuanhao Xie 
>
> This patch synchronizes the No-Execute bit in the IA32_EFER
> register for the APs before the RestoreVolatileRegisters operation.
>
> The commit 964a4f0, titled "Eliminate the second INIT-SIPI-SIPI
> sequence," replaces the second INIT-SIPI-SIPI sequence with the BSP
> calling the SwitchApContext function to initiate a specialized start-up
> signal, waking up APs in the DXE instead of using INIT-SIPI-SIPI.
>
> Due to this change, the logic for "Enable execute disable bit" in
> MpFuncs.nasm is no longer executed. However, to ensure the proper setup
> of the page table, it is necessary to synchronize the IA32_EFER.NXE for
> APs before executing RestoreVolatileRegisters .
>
> Based on SDM:
> If IA32_EFER.NXE is set to 1, it signifies execute-disable, meaning
> instruction fetches are not allowed from the 4-KByte page controlled by
> this entry. Conversely, if it is set to 0, it is reserved.
>
> Signed-off-by: Yuanhao Xie 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 14 +++---
>  UefiCpuPkg/Library/MpInitLib/MpLib.h |  1 +
>  2 files changed, 12 insertions(+), 3 deletions(-)

Good problem description!

>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 9a6ec5db5c..f29e66a14f 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -910,9 +910,16 @@ DxeApEntryPoint (
>CPU_MP_DATA  *CpuMpData
>)
>  {
> -  UINTN  ProcessorNumber;
> +  UINTN   ProcessorNumber;
> +  MSR_IA32_EFER_REGISTER  EferMsr;
>
>GetProcessorNumber (CpuMpData, );
> +  if (CpuMpData->EnableExecuteDisableForSwitchContext) {
> +EferMsr.Uint64   = AsmReadMsr64 (MSR_IA32_EFER);
> +EferMsr.Bits.NXE = 1;
> +AsmWriteMsr64 (MSR_IA32_EFER, EferMsr.Uint64);
> +  }
> +
>RestoreVolatileRegisters (>CpuData[0].VolatileRegisters, FALSE);
>InterlockedIncrement ((UINT32 *)>FinishedCount);
>PlaceAPInMwaitLoopOrRunLoop (
> @@ -2188,8 +2195,9 @@ MpInitLibInitialize (
>  if (MpHandOff->WaitLoopExecutionMode == sizeof (VOID *)) {
>ASSERT (CpuMpData->ApLoopMode != ApInHltLoop);
>
> -  CpuMpData->FinishedCount = 0;
> -  CpuMpData->InitFlag  = ApInitDone;
> +  CpuMpData->FinishedCount= 0;
> +  CpuMpData->InitFlag = ApInitDone;
> +  CpuMpData->EnableExecuteDisableForSwitchContext = 
> IsBspExecuteDisableEnabled ();
>SaveCpuMpData (CpuMpData);
>//
>// In scenarios where both the PEI and DXE phases run in the same
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index 763db4963d..af296f6ac0 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -270,6 +270,7 @@ struct _CPU_MP_DATA {
>UINT64   TotalTime;
>EFI_EVENTWaitEvent;
>UINTN**FailedCpuList;
> +  BOOLEAN  EnableExecuteDisableForSwitchContext;
>
>AP_INIT_STATEInitFlag;
>BOOLEAN  SwitchBspFlag;

Functionally this patch seems fine.

(I cannot test it very usefully, because this code path is not active in
OVMF.)

However, there's one thing I think is less than ideal: after this patch,
we'll have

  MP_CPU_EXCHANGE_INFO . EnableExecuteDisable

but also

  MP_CPU_EXCHANGE_INFO . CpuMpData -> EnableExecuteDisableForSwitchContext

Furthermore, we'll have two invocations of IsBspExecuteDisableEnabled():

- once for the original (HLT loop + INIT-SIPI-SIPI) method, in
  WakeUpAP() -> FillExchangeInfoData(),

- and another time for the new method, in MpInitLibInitialize().

I feel that we should centralize this to one spot.

Note that in commit 629c1dacc9bd ("UefiCpuPkg: ApWakeupFunction directly
use CpuMpData.", 2023-07-11), you changed the prototype of
ApWakeupFunction(), such that it would take CpuMpData directly, rather
than MP_CPU_EXCHANGE_INFO. This was done so that in the next commit
(964a4f032dcd, "UefiCpuPkg: Eliminate the second INIT-SIPI-SIPI
sequence.", 2023-07-11), you could invoke ApWakeupFunction() on *both*
paths, old and new:

- old (INIT-SIPI-SIPI): from the assembly language startup code,

- new: from DxeApEntryPoint().

Therefore, it seems that the *old* field
"MP_CPU_EXCHANGE_INFO.EnableExecuteDisable" is now superfluous. You have
effectively pushed it down to "CpuMpData", so that it's available in
DxeApEntryPoint().

But CpuMpData is similarly available in the assembly language startup
code (that's why you could implement commit 629c1dacc9bd).

So I think this patch is good, but it should be followed with a further
patch: can you please rebase the *old* startup code to the new CpuMpData
field "EnableExecuteDisableForSwitchContext", and then eliminate

Re: [edk2-devel] [Patch V2] UefiCpuPkg/PiSmmCpuDxeSmm: SmmCpuRendezvous ensure all Aps in Present.

[Laszlo Ersek]

On 11/13/23 06:47, Yuanhao Xie wrote:
> SMM read save state requires AP must be present.
> This patch aim to avoid the AP not ready for save state check.
> 
> Signed-off-by: Zhihao Li 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 25 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 13 +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> index 391b64e9f2..cdc7021ee9 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> @@ -406,8 +406,15 @@ SmmCpuRendezvous (
>IN BOOLEANBlockingMode
>)
>  {
> +  UINTN   Index;
> +  UINTN   PresentCount;
> +  UINT32  BlockedCount;
> +  UINT32  DisabledCount;
>EFI_STATUS  Status;
>  
> +  BlockedCount  = 0;
> +  DisabledCount = 0;
> +
>//
>// Return success immediately if all CPUs are already synchronized.
>//
> @@ -426,6 +433,24 @@ SmmCpuRendezvous (
>  // There are some APs outside SMM, Wait for all avaiable APs to arrive.
>  //
>  SmmWaitForApArrival ();
> +
> +//
> +// Make sure all APs have their Present flag set
> +//
> +while (TRUE) {
> +  PresentCount = 0;
> +  for (Index = 0; Index < mMaxNumberOfCpus; Index++) {
> +if (*(mSmmMpSyncData->CpuData[Index].Present)) {
> +  PresentCount++;
> +}
> +  }
> +
> +  GetSmmDelayedBlockedDisabledCount (NULL, , 
> );
> +  if (PresentCount == mMaxNumberOfCpus - BlockedCount - DisabledCount ) {
> +break;
> +  }
> +}
> +
>  Status = mSmmMpSyncData->AllApArrivedWithException ? EFI_SUCCESS : 
> EFI_TIMEOUT;
>} else {
>  //

(1) Here's why I don't like this:

we already have a function that is supposed to do this, and it is
SmmWaitForApArrival().

SmmWaitForApArrival() is called in two contexts. One, in BSPHandler().
Two, here.

Consider the following condition:

  (SyncMode == SmmCpuSyncModeTradition) ||
  SmmCpuFeaturesNeedConfigureMtrrs ()

If this condition evaluates to true, then BSPHandler() calls
SmmWaitForApArrival(), and SmmCpuRendezvous() doesn't.

(This is what the "else" branch in SmmCpuRendezvous() states, in a
comment, too.)

And if the condition evaluates to false, then SmmCpuRendezvous() calls
SmmWaitForApArrival(), and BSPHandler() doesn't.

This patch adds extra waiting logic to *one* of both call sites. And I
don't understand why the *other* call site (in BSPHandler()) does not
need the exact same logic.

In my opinion, this is a sign that SmmWaitForApArrival() isn't "strong
enough". It is not doing all of the work.

In my opinion, *both* call sites should receive this logic (i.e., ensure
that all AP's are "present"), but then in turn, the additional waiting /
checking should be pushed down into SmmWaitForApArrival().

What's your opinion on that?

(2) I notice that a similar "busy loop", waiting for Present flags, is
in BSPHandler().

Do you think we could call CpuPause() in all such "busy loops" (just
before the end of the "while" body)? I think that's supposed to improve
the system's throughput, considered as a whole. The function's comment says,

  Requests CPU to pause for a short period of time. Typically used in MP
  systems to prevent memory starvation while waiting for a spin lock.


Thanks
Laszlo





> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 20ada465c2..b5aa5f99d7 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -1552,6 +1552,19 @@ SmmWaitForApArrival (
>VOID
>);
>  
> +/**
> +  Returns the Number of SMM Delayed & Blocked & Disabled Thread Count.
> +  @param[in,out] DelayedCount  The Number of SMM Delayed Thread Count.
> +  @param[in,out] BlockedCount  The Number of SMM Blocked Thread Count.
> +  @param[in,out] DisabledCount The Number of SMM Disabled Thread Count.
> +**/
> +VOID
> +GetSmmDelayedBlockedDisabledCount (
> +  IN OUT UINT32  *DelayedCount,
> +  IN OUT UINT32  *BlockedCount,
> +  IN OUT UINT32  *DisabledCount
> +  );
> +
>  /**
>Write unprotect read-only pages if Cr0.Bits.WP is 1.
>  



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

Re: [edk2-devel] [PATCH v3 2/2] MdeModulePkg/Bus/Pci/XhciDxe: Fix MISSING_BREAK Coverity issues

[Laszlo Ersek]

On 11/10/23 06:22, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The functions
> XhcInitializeEndpointContext and XhcInitializeEndpointContext64 has
> a switch-case code in which the case USB_ENDPOINT_CONTROL: falls
> through to default:
> 
> While this may be intentional, it may not be evident to any general code
> reader/developer or static analyis tool why there is no break in between.
> 
> Merge the USB_ENDPOINT_CONTROL and default using conditional debug print.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4221
> 
> Cc: Ray Ni 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 33 +++-
>  1 file changed, 19 insertions(+), 14 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> index 05528a478baf..00b3a13a95bb 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> @@ -2825,6 +2825,7 @@ XhcInitializeEndpointContext (
>UINTNNumEp;
>UINTNEpIndex;
>UINT8EpAddr;
> +  UINT8EpType;
>UINT8Direction;
>UINT8Dci;
>UINT8MaxDci;
> @@ -2871,7 +2872,8 @@ XhcInitializeEndpointContext (
>InputContext->EP[Dci-1].MaxBurstSize = 0x0;
>  }
>  
> -switch (EpDesc->Attributes & USB_ENDPOINT_TYPE_MASK) {
> +EpType = EpDesc->Attributes & USB_ENDPOINT_TYPE_MASK;
> +switch (EpType) {
>case USB_ENDPOINT_BULK:
>  if (Direction == EfiUsbDataIn) {
>InputContext->EP[Dci-1].CErr   = 3;
> @@ -2974,13 +2976,13 @@ XhcInitializeEndpointContext (
>  
>  break;
>  
> -  case USB_ENDPOINT_CONTROL:
> -//
> -// Do not support control transfer now.
> -//
> -DEBUG ((DEBUG_INFO, "XhcInitializeEndpointContext: Unsupport Control 
> EP found, Transfer ring is not allocated.\n"));
>default:
> -DEBUG ((DEBUG_INFO, "XhcInitializeEndpointContext: Unknown EP found, 
> Transfer ring is not allocated.\n"));
> +DEBUG ((
> +  DEBUG_INFO,
> +  "%a: %a found, Transfer ring is not allocated.\n",
> +  __func__,
> +  (EpType == USB_ENDPOINT_CONTROL ? "Unsupported Control EP" : 
> "Unknown EP")
> +  ));
>  EpDesc = (USB_ENDPOINT_DESCRIPTOR *)((UINTN)EpDesc + EpDesc->Length);
>  continue;
>  }
> @@ -3028,6 +3030,7 @@ XhcInitializeEndpointContext64 (
>UINTNNumEp;
>UINTNEpIndex;
>UINT8EpAddr;
> +  UINT8EpType;
>UINT8Direction;
>UINT8Dci;
>UINT8MaxDci;
> @@ -3074,7 +3077,8 @@ XhcInitializeEndpointContext64 (
>InputContext->EP[Dci-1].MaxBurstSize = 0x0;
>  }
>  
> -switch (EpDesc->Attributes & USB_ENDPOINT_TYPE_MASK) {
> +EpType = EpDesc->Attributes & USB_ENDPOINT_TYPE_MASK;
> +switch (EpType) {
>case USB_ENDPOINT_BULK:
>  if (Direction == EfiUsbDataIn) {
>InputContext->EP[Dci-1].CErr   = 3;
> @@ -3177,13 +3181,14 @@ XhcInitializeEndpointContext64 (
>  
>  break;
>  
> -  case USB_ENDPOINT_CONTROL:
> -//
> -// Do not support control transfer now.
> -//
> -DEBUG ((DEBUG_INFO, "XhcInitializeEndpointContext64: Unsupport 
> Control EP found, Transfer ring is not allocated.\n"));
>default:
> -DEBUG ((DEBUG_INFO, "XhcInitializeEndpointContext64: Unknown EP 
> found, Transfer ring is not allocated.\n"));
> +DEBUG ((
> +  DEBUG_INFO,
> +  "%a: %a found, Transfer ring is not allocated.\n",
> +  __func__,
> +  ((EpType == USB_ENDPOINT_CONTROL) ? "Unsupported Control EP" : 
> "Unknown EP")
> +  ));
> +
>  EpDesc = (USB_ENDPOINT_DESCRIPTOR *)((UINTN)EpDesc + EpDesc->Length);
>  continue;
>  }

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v3 1/2] MdeModulePkg/Bus/Pci/XhciDxe: Fix FORWARD_NULL Coverity issues

[Laszlo Ersek]

On 11/10/23 06:22, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The functions UsbHcGetHostAddrForPciAddr, UsbHcGetPciAddrForHostAddr
> and UsbHcFreeMem do have
> 
> ASSERT ((Block != NULL));
> 
> statements after for loop, but these are applicable only in DEBUG mode.
> In RELEASE mode, if for whatever reasons there is no match inside for
> loop and the loop exits because of Block != NULL; condition, then there
> is no "Block" NULL pointer check afterwards and the code proceeds to do
> dereferencing "Block" which will lead to CRASH.
> 
> Hence, for safety add NULL pointer checks always.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4221
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c | 29 
>  1 file changed, 29 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c 
> b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> index b54187ec228e..597cbe4646e8 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> @@ -267,6 +267,16 @@ UsbHcGetPciAddrForHostAddr (
>}
>  
>ASSERT ((Block != NULL));
> +
> +  if (Block == NULL) {
> +//
> +// Should never be here
> +//
> +DEBUG ((DEBUG_ERROR, "UsbHcGetPciAddrForHostAddr: Invalid host memory 
> pointer passed\n"));
> +CpuDeadLoop ();
> +return 0;
> +  }
> +
>//
>// calculate the pci memory address for host memory address.
>//
> @@ -322,6 +332,16 @@ UsbHcGetHostAddrForPciAddr (
>}
>  
>ASSERT ((Block != NULL));
> +
> +  if (Block == NULL) {
> +//
> +// Should never be here
> +//
> +DEBUG ((DEBUG_ERROR, "UsbHcGetHostAddrForPciAddr: Invalid pci memory 
> pointer passed\n"));
> +CpuDeadLoop ();
> +return 0;
> +  }
> +
>//
>// calculate the pci memory address for host memory address.
>//
> @@ -603,6 +623,15 @@ UsbHcFreeMem (
>//
>ASSERT (Block != NULL);
>  
> +  if (Block == NULL) {
> +//
> +// Should never be here
> +//
> +DEBUG ((DEBUG_ERROR, "UsbHcFreeMem: Invalid memory pointer passed\n"));
> +CpuDeadLoop ();
> +return;
> +  }
> +
>//
>// Release the current memory block if it is empty and not the head
>//

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v3 2/2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe: Fix MISSING_BREAK Coverity issue

[Laszlo Ersek]

exhausted.

>
>  DEBUG ((
>DEBUG_INFO,
>" %s: Granularity/SpecificFlag = %ld / %02x%s\n",
>mAcpiAddressSpaceTypeStr[Descriptor->ResType],
>Descriptor->AddrSpaceGranularity,
>Descriptor->SpecificFlag,
>(Descriptor->SpecificFlag & 
> EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE) != 0 ? L" 
> (Prefetchable)" : L""
>));
>  DEBUG ((DEBUG_INFO, "  Length/Alignment = 0x%lx / 0x%lx\n", 
> Descriptor->AddrLen, Descriptor->AddrRangeMax));
> -switch (Descriptor->ResType) {
> -  case ACPI_ADDRESS_SPACE_TYPE_MEM:
> +
> +if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
>if ((Descriptor->AddrSpaceGranularity != 32) && 
> (Descriptor->AddrSpaceGranularity != 64)) {
>  return EFI_INVALID_PARAMETER;
>}
>
>if ((Descriptor->AddrSpaceGranularity == 32) && 
> (Descriptor->AddrLen >= SIZE_4GB)) {
>  return EFI_INVALID_PARAMETER;
>}
>
>//
>// If the PCI root bridge does not support separate windows for 
> nonprefetchable and
>// prefetchable memory, then the PCI bus driver needs to include 
> requests for
>// prefetchable memory in the nonprefetchable memory pool.
>//
>if (((RootBridge->AllocationAttributes & 
> EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM) != 0) &&
>((Descriptor->SpecificFlag & 
> EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE) != 0)
>)
>{
>  return EFI_INVALID_PARAMETER;
>}
> +}
>
> -  case ACPI_ADDRESS_SPACE_TYPE_IO:
>  //
>  // Check aligment, it should be of the form 2^n-1
>  //
>  if (GetPowerOfTwo64 (Descriptor->AddrRangeMax + 1) != 
> (Descriptor->AddrRangeMax + 1)) {
>return EFI_INVALID_PARAMETER;
>  }
> -
> -break;
> -  default:
> -ASSERT (FALSE);
> -break;
> -}
>}

The patch is good and clever thus far. We restrict the types we handle
to MEM and IO. Then we have a block of code that runs only for MEM, and
then another that -- due to being unrestricted -- runs for both MEM and
IO.

>
>if (Descriptor->Desc != ACPI_END_TAG_DESCRIPTOR) {
>  return EFI_INVALID_PARAMETER;
>}
>
>for (Descriptor = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *)Configuration; 
> Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR; Descriptor++) {
>  if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
>if (Descriptor->AddrSpaceGranularity == 32) {
>  if ((Descriptor->SpecificFlag & 
> EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE) != 0) {
>Type = TypePMem32;
>  } else {
>Type = TypeMem32;
>  }
>} else {
> -ASSERT (Descriptor->AddrSpaceGranularity == 64);
>  if ((Descriptor->SpecificFlag & 
> EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE) != 0) {
>Type = TypePMem64;
>  } else {
>Type = TypeMem64;
>  }
>}
>  } else {
> -  ASSERT (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_IO);
>Type = TypeIo;
>  }

But the removal of these ASSERT()s is hard to justify.

Yes, these predicates are always TRUE at this point, due to checks
performed above.

But that's *exactly the reason* for including an ASSERT() in the code!
To remind the reader that a (perhaps non-obvious) predicate always holds
at that location!

So, the argument

  ASSERT(X) is unneeded because X always holds

is backwards. You do an ASSERT(X) *because* X always holds, and X is
non-trivial!

The only reason for removing an ASSERT(X) is that X, while true, is
*trivial*.

In this particular case, we do indeed explicitly restrict
Descriptor->AddrSpaceGranularity to 32 or 64 above, on the MEM branch.

We also ensure that the only resource type other than MEM can be IO.

In other words, the assertions are true.

Now the question is: are those true statements *trivial*? If they are
trivial, then removing them is OK. If they are not trivial, then they
are worth keeping.

In my opinion, they are worth keeping. They are *reminders* that we
performed those checks above.

But I'm not going to die on this hill, so if you don't want to respin:

Reviewed-by: Laszlo Ersek 

Laszlo

>
>  RootBridge->ResAllocNode[Type].Length= Descriptor->AddrLen;
>  RootBridge->ResAllocNode[Type].Alignment = Descriptor->AddrRangeMax;
>  RootBridge->ResAllocNode[Type].Status= ResSubmitted;
>}
>
>RootBridge->ResourceSubmitted = TRUE;
>return EFI_SUCCESS;
>  }
>}
>
>return EFI_INVALID_PARAMETER;
>  }



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

Re: [edk2-devel] [PATCH v3 1/2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe: Fix OVERRUN Coverity issues

[Laszlo Ersek]

On 11/10/23 05:07, Ranbir Singh wrote:
> Options before us till now -
> 
> 1. Add array overrun check and Debug statement before CpuDeadLoop within

This would be useless.

Your current patch implements the following pattern:

  ASSERT (X);
  if (!X) {
CpuDeadLoop ();
  }

Option#1 would mean

  ASSERT (X);
  if (!X) {
DEBUG ((DEBUG_ERROR, "%a: condition X failed\n", __func__));
CpuDeadLoop ();
  }

Now compare the behavior of both code snippets.

- In DEBUG and NOOPT builds, if X evaluated to FALSE, then the ASSERT()
would fire. A DEBUG_ERROR message would be logged, including "X", the
file name, and the line number. ASSERT() would then enter CpuDeadLoop()
internally, or invoke CpuBreakpoint() -- dependent on platform PCD
configuration. This applies to both snippets. In particular, the
explicit DEBUG and CpuDeadLoop() would not be reached, in the second
snippet. In other words, in DEBUG and NOOPT builds, the difference is
unobservable.

- In RELEASE builds, the ASSERT() is compiled out of both snippets.
Furthermore, the explicit DEBUG is compiled out of the second snippet.
That is, both code snippets would silently enter CpuDeadLoop(). In other
words, the behavior of both snippets is undistinguishable in RELEASE
builds too.

In my opinion, the current patch is right.

Reviewed-by: Laszlo Ersek 


To elaborate on that more generally:

Core edk2 code has so consistently and so broadly *abused* and *misused*
ASSERT() for error checking, that now we fail to recognize an *actual
valid use* of ASSERT() for what it is. For illustration, compare the
following two code snippets:

(a)

  UINTN Val;

  Val = 1 + 2;
  ASSERT (Val == 3);

(b)

  VOID *Ptr;

  Ptr = AllocatePool (1024);
  ASSERT (Ptr != NULL);

Snippet (a) is a *valid* use of an assert. It encapsulates a logical
predicate about the program's state, based on algorithmic and
mathematical reasoning. If the predicate turns out not to hold in
practice, at runtime,that means the programmer has retroactively caught
an issue in their own thinking, the algorithm is incorrectly designed or
implemented, and the program's state is effectively unknown at this
point (the internal invariant in question is broken), and so we must
stop immediately, because we don't know what the program is going to do
next. Given that what we thought about the program *thus far* has now
turned out to be false.

Snippet (b) is an abuse of assert. AllocatePool()'s result depends on
the environment. Available memory, input data seen from the user or the
disk or the network thus far, and a bunch of other things not under our
control. Therefore, we must explicitly deal with AllocatePool() failing.
Claiming that AllocatePool() will succeed is wrong because we generally
cannot even *attempt* to prove it.

In case (a) however, we can actually make a plausible attempt at
*proving* the predicate. The assert is there just in case our proof is
wrong.

There's an immense difference between situations (a) and (b). I cannot
emphasize that enough. Case (a) is a provable statement about the
behavior of an algorithm. Case (b) is a *guess* at input data and
environment.

The problem with edk2 core is that it has so consistently abused
ASSERT() for case (b) that now, when we occasionally see a *valid
instance* of (a), we mistake it for (b).

That's the case here. The ASSERT() seen in this patch is case (a). It's
just that Coverity cannot prove it itself, because the predicate we
assert is much more complicated than (1 + 2 == 3). But that doesn't
change the fact that we have a proof for the invariant in question.

Therefore, the solution is not to try to handle an impossible error
gracefully. The solution is two-fold:

- Tell coverity that we have a proof, in terms that it understands, to
shut it up. The terminology for this is CpuDeadLoop(). We're willing to
hang at runtime even in RELEASE builds, if the condition fails.

- If, at runtime, our proof turns out to be wrong indeed, then we must
stop immediately (because if 1+2 stops equalling 3, then we can't trust
*anything else* that our program would do).

(The more generic corollary of my last point, by the way, is that
ASSERT()s should NEVER be compiled out of programs. And if we actually
did that, like many other projects do, then this Coverity warning
wouldn't even exist, in the first place, because Coverity would *always*
see -- with the ASSERT() being there in all builds -- a range check on
Index.

Put differently, having to add a CpuDeadLoop() explicitly is just
"damage control" for the self-inflicted damage of compiling out ASSERTs.)

Laszlo



> 2. Status Quo (not everything can be ideal :-))
> 
> Question before us
>      - Is 1 better than 2 ?
> 
> 
> On Fri, Nov 10, 2023 at 8:41 AM Ranbir Singh  <mailto:rsi...@ventanamicro.com>> wrote:
> 
> As far as I know, from a secure coding perspective, it would be
> recommended that array overrun condition

Re: [edk2-devel] [PATCH v3 1/2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe: Fix OVERRUN Coverity issues

[Laszlo Ersek]

On 11/9/23 21:40, Michael D Kinney wrote:
> Hi Ranbir,
> 
> A deadloop without even a debug print is not good behavior.

In DEBUG and NOOPT builds, the ASSERT() would fire, hence providing a
debug message.

In RELEASE builds, even if there were a separate DEBUG message, the
DEBUG would be compiled out.

> 
> If this condition really represents a condition where it is not possible
> to complete the PCI resource allocation/assignment, then an error status
> code should be returned to the caller of NotifyPhase().

That's not the case here. This ASSERT() really cannot fire:

  https://edk2.groups.io/g/devel/message/110856

In other words, it is a *true* genuine assertion.

It's only that Coverity cannot see that.

Thus the idea here is to tell Coverity that we're willing to hang even
in RELEASE builds. That hang will never ever occur (it can't), but by
adding the explicit CpuDeadLoop(), we can placate Coverity (hopefully).

Put differently: if we had an ASSERT() variant that could not be
compiled out of RELEASE builds, then we'd use that variant here.

Laszlo

> Perhaps
> EFI_OUT_OF_RESOURCES.  The other ASSERT() conditions in this API should
> likely be updated to do the same.
> 
> This may also require the caller of this service, the PCI Bus Driver,
> to be reviewed to make sure it handles error conditions from NotifyPhase().
> 
> I recommend you get help on the proposed code changes from the PCI
> subsystem maintainers.
> 
> Thanks,
> 
> Mike
> 
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Ranbir
>> Singh
>> Sent: Thursday, November 9, 2023 9:39 AM
>> To: devel@edk2.groups.io; rsi...@ventanamicro.com
>> Cc: Ni, Ray ; Veeresh Sangolli
>> 
>> Subject: [edk2-devel] [PATCH v3 1/2]
>> MdeModulePkg/Bus/Pci/PciHostBridgeDxe: Fix OVERRUN Coverity issues
>>
>> From: Ranbir Singh 
>>
>> The function NotifyPhase has a check
>>
>> ASSERT (Index < TypeMax);
>>
>> but this comes into play only in DEBUG mode. In Release mode, there is
>> no handling if the Index value is within array limits or not. If for
>> whatever reasons, the Index does not get re-assigned to Index2 at line
>> 937, then it remains at TypeMax as assigned earlier at line 929. This
>> poses array overrun risk at lines 942 and 943. It is better to deploy
>> a safety check on Index limit before accessing array elements.
>>
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4212
>>
>> Cc: Ray Ni 
>> Co-authored-by: Veeresh Sangolli 
>> Signed-off-by: Ranbir Singh 
>> Signed-off-by: Ranbir Singh 
>> ---
>>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> index d573e532bac8..c2c143068cd2 100644
>> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> @@ -939,6 +939,11 @@ NotifyPhase (
>>  }
>>
>>
>>
>>  ASSERT (Index < TypeMax);
>>
>> +
>>
>> +if (Index == TypeMax) {
>>
>> +  CpuDeadLoop ();
>>
>> +}
>>
>> +
>>
>>  ResNodeHandled[Index] = TRUE;
>>
>>  Alignment = RootBridge-
>>> ResAllocNode[Index].Alignment;
>>
>>  BitsOfAlignment   = LowBitSet64 (Alignment + 1);
>>
>> --
>> 2.34.1
>>
>>
>>
>> -=-=-=-=-=-=
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#110993):
>> https://edk2.groups.io/g/devel/message/110993
>> Mute This Topic: https://groups.io/mt/102490513/1643496
>> Group Owner: devel+ow...@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>> [michael.d.kin...@intel.com]
>> -=-=-=-=-=-=
>>
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v1] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

[Laszlo Ersek]

On 11/13/23 16:38, Laszlo Ersek wrote:
> On 11/7/23 03:43, Wu, Jiaxin wrote:
>> Processor extended information is filled when
>> CPU_V2_EXTENDED_TOPOLOGY is set in parameter ProcessorNumber
>> from GetProcessorInfo() (See commit: 1fadd18d).
>>
>> This filed value is retrieved from CPUID leaf 1FH, which is
>> a preferred superset to leaf 0BH.
>>
>> Since Intel recommends first use the CPUID leaf 1FH instead of
>> leaf 0BH, this patch change to use the processor extended
>> information, which can reflect the value from CPUID leaf 1FH.
>>
>> Cc: Eric Dong 
>> Cc: Ray Ni 
>> Cc: Rahul Kumar 
>> Cc: Gerd Hoffmann 
>> Cc: Star Zeng 
>> Signed-off-by: Jiaxin Wu 
>> ---
>>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 10 ++
>>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  6 +++---
>>  2 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c 
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
>> index 391b64e9f2..c0485b0519 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
>> @@ -169,10 +169,20 @@ SmmAddProcessor (
>>  >ProcessorInfo[Index].Location.Package,
>>  >ProcessorInfo[Index].Location.Core,
>>  >ProcessorInfo[Index].Location.Thread
>>  );
>>  
>> +  GetProcessorLocation2ByApicId (
>> +(UINT32)ProcessorId,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Package,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Die,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Tile,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Module,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Core,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Thread
>> +);
>> +
>>*ProcessorNumber = Index;
>>gSmmCpuPrivate->Operation[Index] = SmmCpuAdd;
>>return EFI_SUCCESS;
>>  }
>>}
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>> index 25d058c5b9..c61562c867 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>> @@ -177,11 +177,11 @@ IsPackageFirstThread (
>>IN UINTN  CpuIndex
>>)
>>  {
>>UINT32  PackageIndex;
>>  
>> -  PackageIndex =  gSmmCpuPrivate->ProcessorInfo[CpuIndex].Location.Package;
>> +  PackageIndex =  
>> gSmmCpuPrivate->ProcessorInfo[CpuIndex].ExtendedInformation.Location2.Package;
>>  
>>ASSERT (mPackageFirstThreadIndex != NULL);
>>  
>>//
>>// Set the value of mPackageFirstThreadIndex[PackageIndex].
>> @@ -1834,12 +1834,12 @@ InitPackageFirstThreadIndexInfo (
>>  
>>//
>>// Count the number of package, set to max PackageId + 1
>>//
>>for (Index = 0; Index < mNumberOfCpus; Index++) {
>> -if (PackageId < gSmmCpuPrivate->ProcessorInfo[Index].Location.Package) {
>> -  PackageId = gSmmCpuPrivate->ProcessorInfo[Index].Location.Package;
>> +if (PackageId < 
>> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package) {
>> +  PackageId = 
>> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package;
>>  }
>>}
>>  
>>PackageCount = PackageId + 1;
>>  
> 
> Regression-tested-by: Laszlo Ersek 
> 

also

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v1] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

[Laszlo Ersek]

On 11/7/23 03:43, Wu, Jiaxin wrote:
> Processor extended information is filled when
> CPU_V2_EXTENDED_TOPOLOGY is set in parameter ProcessorNumber
> from GetProcessorInfo() (See commit: 1fadd18d).
> 
> This filed value is retrieved from CPUID leaf 1FH, which is
> a preferred superset to leaf 0BH.
> 
> Since Intel recommends first use the CPUID leaf 1FH instead of
> leaf 0BH, this patch change to use the processor extended
> information, which can reflect the value from CPUID leaf 1FH.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Star Zeng 
> Signed-off-by: Jiaxin Wu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 10 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  6 +++---
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> index 391b64e9f2..c0485b0519 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> @@ -169,10 +169,20 @@ SmmAddProcessor (
>  >ProcessorInfo[Index].Location.Package,
>  >ProcessorInfo[Index].Location.Core,
>  >ProcessorInfo[Index].Location.Thread
>  );
>  
> +  GetProcessorLocation2ByApicId (
> +(UINT32)ProcessorId,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Package,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Die,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Tile,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Module,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Core,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Thread
> +);
> +
>*ProcessorNumber = Index;
>gSmmCpuPrivate->Operation[Index] = SmmCpuAdd;
>return EFI_SUCCESS;
>  }
>}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 25d058c5b9..c61562c867 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -177,11 +177,11 @@ IsPackageFirstThread (
>IN UINTN  CpuIndex
>)
>  {
>UINT32  PackageIndex;
>  
> -  PackageIndex =  gSmmCpuPrivate->ProcessorInfo[CpuIndex].Location.Package;
> +  PackageIndex =  
> gSmmCpuPrivate->ProcessorInfo[CpuIndex].ExtendedInformation.Location2.Package;
>  
>ASSERT (mPackageFirstThreadIndex != NULL);
>  
>//
>// Set the value of mPackageFirstThreadIndex[PackageIndex].
> @@ -1834,12 +1834,12 @@ InitPackageFirstThreadIndexInfo (
>  
>//
>// Count the number of package, set to max PackageId + 1
>//
>for (Index = 0; Index < mNumberOfCpus; Index++) {
> -if (PackageId < gSmmCpuPrivate->ProcessorInfo[Index].Location.Package) {
> -  PackageId = gSmmCpuPrivate->ProcessorInfo[Index].Location.Package;
> +    if (PackageId < 
> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package) {
> +  PackageId = 
> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package;
>  }
>}
>  
>PackageCount = PackageId + 1;
>  

Regression-tested-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v1 1/1] Bug 2861 - HiiDatabaseDxe, ConfigRouting.c, GetElementsFromRequest incorrect error handling.

[Laszlo Ersek]

Hi Charles,

On 10/26/23 03:05, Charles Hyde wrote:
> From: Charles Hyde 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2861
> 
> I believe the attached ConfigRouting.txt patch will resolve bug 2861, plus
> resolve an uninitialized pointer issue in HiiConfigRoutingExportConfig().
> The uninitialized pointer was identified when running the EDK2 Self
> Certification Test with all tests selected, having caused the CPU to issue
> an exception error (most times) or completely trashed the system
> (sometimes).
> 
> I found a second instance of GetElementsFromRequest(), located in HiiLib.c,
> that also needed an update.  The attached patch should address this bug and
> more.
> 
> Signed-off-by: Charles Hyde 
> ---

Thanks for analyzing and fixing these bugs.

Can you please split the separate fixes to separate patches?

Also, the patch looks garbled; it shouldn't be attached / pasted but
sent with git-send-email. Are you familiar with git-send-email?

Here's the official docs:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

and some unofficial tips:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

Third, I suggest not to comment out, with /* */, dead code (such as a
subcondition that always evaluates to false or true); instead, remove
it, and explain in the commit message (or, if necessary, in a code
comment) why that condition is a tautology. If the condition or argument
is nontrivial, consider using an ASSERT().

Laszlo


> 
> diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> index 63a37ab59a..c3dc7bf558 100644
> --- a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> +++ b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> @@ -2272,8 +2272,14 @@ GetElementsFromRequest (
> {
>   EFI_STRING  TmpRequest;
> 
> +  ASSERT (ConfigRequest != NULL);
> +  if (ConfigRequest == NULL)
> +    return FALSE;
> +
>   TmpRequest = StrStr (ConfigRequest, L"PATH=");
>   ASSERT (TmpRequest != NULL);
> +  if (TmpRequest == NULL)
> +    return FALSE;
> 
>   if ((StrStr (TmpRequest, L"=") != NULL) || (StrStr (TmpRequest,
> L"&") != NULL)) {
>     return TRUE;
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> index 5ae6189a28..0b39f156f3 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> @@ -420,14 +420,19 @@ AppendToMultiString (
>   }
> 
>   AppendStringSize = StrSize (AppendString);
> +  if (AppendStringSize <= sizeof(*AppendString))    // If the string is
> empty, there is no need to proceed further.
> +    return EFI_SUCCESS;
> +
>   MultiStringSize  = StrSize (*MultiString);
>   MaxLen   = MAX_STRING_LENGTH / sizeof (CHAR16);
> 
>   //
>   // Enlarge the buffer each time when length exceeds MAX_STRING_LENGTH.
>   //
> -  if ((MultiStringSize + AppendStringSize > MAX_STRING_LENGTH) ||
> -  (MultiStringSize > MAX_STRING_LENGTH))
> +  if ((MultiStringSize + AppendStringSize > MAX_STRING_LENGTH) /*||
> +  (MultiStringSize > MAX_STRING_LENGTH)*/)  // There is no need to
> check the second part.
> +    // If the first part is
> false, the second part will always be false.
> +    // If the second part is
> true, the first part must also be true.
>   {
>     *MultiString = (EFI_STRING)ReallocatePool (
>  MultiStringSize,
> @@ -1800,8 +1805,14 @@ GetElementsFromRequest (
> {
>   EFI_STRING  TmpRequest;
> 
> +  ASSERT (ConfigRequest != NULL);
> +  if (ConfigRequest == NULL)
> +    return FALSE;
> +
>   TmpRequest = StrStr (ConfigRequest, L"PATH=");
>   ASSERT (TmpRequest != NULL);
> +  if (TmpRequest == NULL)
> +    return FALSE;
> 
>   if ((StrStr (TmpRequest, L"=") != NULL) || (StrStr (TmpRequest,
> L"&") != NULL)) {
>     return TRUE;
> @@ -5292,6 +5303,7 @@ HiiConfigRoutingExportConfig (
>     //
>     IfrDataParsedFlag = FALSE;
>     Progress  = NULL;
> +    AccessResults = NULL;
>     HiiHandle = NULL;
>     DefaultResults    = NULL;
>     Database  = NULL;
> @@ -5326,6 +5338,14 @@ HiiConfigRoutingExportConfig (
>  
>  );
>     if (EFI_ERROR (Status)) {
> +
> +  // If an error was returned, then do not believe any results in
> these
> two pointers.
> +  Progress = NULL;
> +  if (AccessResults) {
> +    FreePool (AccessResults);
> +    AccessResults = NULL;
> +  }
> +
>   //
>   // Update AccessResults by getting default setting from IFR when
> HiiPackage is registered to HiiHandle
>   //
> @@ -5350,6 +5370,17 @@ HiiConfigRoutingExportConfig (
>     }
> 
>     if (!EFI_ERROR (Status)) {
> +
> +  // If AccessResults == NULL, there is nothing to be done.
> +  if 

Re: [edk2-devel] [PATCH edk2-test v2 4/4] Fix the URL for the edk2-test repo

[Laszlo Ersek]

On 11/10/23 20:08, Rebecca Cran wrote:
> Fix the URL for the edk2-test repo: the uefi-sct is a directory inside
> the repo.
> 
> Signed-off-by: Rebecca Cran 
> Contributed-under: TianoCore Contribution Agreement 1.1
> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index a94255f015ad..ae6dd7008bcd 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -28,7 +28,7 @@ Descriptions of section entries:
>  
>  UEFI-SCT
>  --
> -T: git - https://github.com/tianocore/edk2-test/uefi-sct
> +T: git - https://github.com/tianocore/edk2-test
>  
>  
>  Responsible Disclosure, Reporting Security Issues

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.

[Laszlo Ersek]

On 11/9/23 03:51, duntan wrote:
> Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
> 
> Previously, the HOB is defined, created and consumed only in StandaloneMmPkg. 
> The HOB contains the number
> of processors and EFI_PROCESSOR_INFORMATION structure. This is the same as 
> the information that PiSmmCpuDxeSmm
> uses EfiMpServiceProtocolGuid to get.
> 
> The incoming plan is to create gMpInformationHobGuid for both StandaloneMm 
> and legacy DXE_SMM in early
> phase(for example in CpuMpPei). Then PiSmmCpuDxeSmm can consume the hob, 
> which can simplify code logic
> in PiSmmCpuDxeSmm driver.
> 
> So move this HOB definition to UefiCpuPkg in this patch series.
> 
> Dun Tan (3):
>   UefiCpuPkg: Create MpInformation.h in UefiCpuPkg
>   StandaloneMmPkg:Add UefiCpuPkg.dec in DependencyCheck
>   StandaloneMmPkg:Remove MpInformation.h
> 
>  StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf  
>  | 1 +
>  
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
>  | 1 +
>  StandaloneMmPkg/StandaloneMmPkg.ci.yaml  
>  | 3 ++-
>  StandaloneMmPkg/StandaloneMmPkg.dec  
>  | 1 -
>  {StandaloneMmPkg => UefiCpuPkg}/Include/Guid/MpInformation.h 
>  | 2 +-
>  UefiCpuPkg/UefiCpuPkg.dec
>  | 3 +++
>  6 files changed, 8 insertions(+), 3 deletions(-)
>  rename {StandaloneMmPkg => UefiCpuPkg}/Include/Guid/MpInformation.h (88%)
> 

>From a quick skim, the series looks OK to me, and I also agree that the
above two MP services calls (GetNumberOfProcessors, GetProcessorInfo)
seem to be the only ones in PiSmmCpuDxeSmm.

However, what about the following scenario:

- in the PI phase (or HOB producer phase), the HOB is produced

- in the DXE phase, a platform DXE driver uses EFI_MP_SERVICES_PROTOCOL
to change some aspect of the processors in the system. For example, it
calls SwitchBSP, or calls EnableDisableAP.

- Then the information in the HOB will be stale, once PiSmmCpuDxeSmm
consumes it. The EFI_PROCESSOR_INFORMATION.StatusFlag field carries
information both about the CPU in question being BSP vs. AP, and about
the CPU being enabled or disabled. So either of SwitchBSP() and
EnableDisableAP() can invalidate the StatusFlag field for a given
ProcessorId.

I don't know how StandaloneMmPkg currently deals with this scenario, and
I also don't know whether StatusFlag actually matters to PiSmmCpuSmmDxe.
Apparently, it doesn't. So technically, the replacement of the protocol
with the HOB should be fine, but for the general case, we should
document somehow that specific fields of the HOB may be invalidated
between HOB production and HOB consumption. If platform code is required
to prevent that (i.e., the platform is responsible for not calling
SwitchBSP() or EnableDisableAP()), then that requirement should also be
documented.

Acked-by: Laszlo Ersek 


Thanks
Laszlo



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

Re: [edk2-devel] CodeQL Analysis in edk2

[Laszlo Ersek]

sorry, unfinished thought:

On 11/13/23 14:39, Laszlo Ersek wrote:

> - the "sarif emacs" output seems a bit broken, actually, so it's not usable. 
> Consider the following entry from the original JSON file:
> 
> }, {
>   "ruleId" : "cpp/missing-null-test",
>   "ruleIndex" : 0,
>   "rule" : {
> "id" : "cpp/missing-null-test",
> "index" : 0
>   },
>   "message" : {
> "text" : "Value may be null; it should be checked before 
> dereferencing."
>   },
>   "locations" : [ {
> "physicalLocation" : {
>   "artifactLocation" : {
> "uri" : 
> "MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c",
> "uriBaseId" : "%SRCROOT%",
> "index" : 0
>   },
>   "region" : {
> "startLine" : 355,
> "startColumn" : 48,
> "endColumn" : 52
>   }
> }
>   } ],
>   "partialFingerprints" : {
> "primaryLocationLineHash" : "f374f6e6dfc92010:1",
> "primaryLocationStartColumnFingerprint" : "43"
>   }
> }, {
> 
> In the "emacs" output, it appears as:
> 
> 
> ModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c:355: 
> cpp/missing-null-test Value may be null; it should be checked before 
> dereferencing.
> 
> 
> Note that the first three characters, "Mde" of "Mde" are lost.

I meant '"Mde" of "ModulePkg"'.

> 
> This issue (first three chars cut) affects all other pathnames in the emacs 
> output too.




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

Re: [edk2-devel] CodeQL Analysis in edk2

[Laszlo Ersek]

On 11/7/23 16:43, Michael Kubacki wrote:
> The series that makes it easy to run CodeQL locally and have access to
> results from any PR or push to master.
> 
> Those that have access can see the results directly in "Code Scanning"
> in the "Security" tab of the edk2 repo. That may be affected in times
> like freezes when permissions are adjusted (write permission is needed).
> 
> I am hoping we can work together to improve the overall quality of the
> code and minimize the number of CodeQL alerts.
> 
> This is an example of that interface:
> 
> *Overview of Issues (many)*
> 
> 
> *Example of Details for a Specific Issue*
> 
> *---*
> 
> *However, you can always download the results for an individual package*
> from its GitHub Action run. I encourage people to do so.
> 
> 1. Go to Actions -> CodeQL
> 
> (https://github.com/tianocore/edk2/actions/workflows/codeql.yml).
> Anything to "master" are results at that point in time on the master
> branch. Individual PR branches are shown to get results for a specific PR.
> 
> 
> 
> 2. Download and open the SARIF file for a package. In the commit to
> master shown above in
> https://github.com/tianocore/edk2/actions/runs/6779575049, for
> MdeModulePkg, I would download "MdeModulePkg-CodeQL-SARIF" and unzip.
> 
> 
> 
> 3. Open the SARIF file to view results. For example, drag/drop the file
> "codeql-db-mdemodulepkg-debug-0.sarif" into VS Code with the "SARIF
> Viewer"
> 
>  installed. It shows all of the issues by file or rule with click to the 
> problem and more details about it. There are other SARIF viewers available as 
> well.

I've investigated "sarif", from "sarif-tools version 2.0.0", at 
.

The "emacs" output module of "sarif" would be ideal for my needs, but I have 
two questions / requests regarding that:

- would it be possible to run "sarif emacs" immediately in the github action, 
so that the text file can be downloaded at once? (I currently have sarif-tools 
installed in a python venv, but I'd prefer avoiding even that.)

- the "sarif emacs" output seems a bit broken, actually, so it's not usable. 
Consider the following entry from the original JSON file:

}, {
  "ruleId" : "cpp/missing-null-test",
  "ruleIndex" : 0,
  "rule" : {
"id" : "cpp/missing-null-test",
"index" : 0
  },
  "message" : {
"text" : "Value may be null; it should be checked before dereferencing."
  },
  "locations" : [ {
"physicalLocation" : {
  "artifactLocation" : {
"uri" : 
"MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c",
"uriBaseId" : "%SRCROOT%",
"index" : 0
  },
  "region" : {
"startLine" : 355,
"startColumn" : 48,
"endColumn" : 52
  }
}
  } ],
  "partialFingerprints" : {
"primaryLocationLineHash" : "f374f6e6dfc92010:1",
"primaryLocationStartColumnFingerprint" : "43"
  }
}, {

In the "emacs" output, it appears as:


ModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c:355: 
cpp/missing-null-test Value may be null; it should be checked before 
dereferencing.


Note that the first three characters, "Mde" of "Mde" are lost.

This issue (first three chars cut) affects all other pathnames in the emacs 
output too.

Is this a known issue perhaps?

Thanks!
Laszlo

> 
> 
> 
> Keep in mind that CodeQL will often not highlight everything that needs
> to be done to fix an issue. It alerts the developer to an issue and then
> you need to inspect the code to determine if other code paths or
> refactoring should be applied.
> 
> I will create a wiki page with more user focused information, but I
> wanted to share some quick info for getting started.
> 
> More technical details about how the plugin itself works and applying
> exceptions are available in its readme
> - edk2/BaseTools/Plugin/CodeQL/Readme.md at master · tianocore/edk2
> (github.com).
> 
> 
> Thanks,
> Michael
> 



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

Re: [edk2-devel] [PATCH 0/2] Remove string IO instruction in BaseIoLibIntrinsic.inf

[Laszlo Ersek]

On 11/9/23 06:56, Ni, Ray wrote:
> Reviewed-by: Ray Ni 
> 
> Thanks for providing the alternative solution that avoids impacting OVMF
> boot performance.

This approach looks good to me.

The IA32 and X64 OVMF platforms use "BaseIoLibIntrinsicSev.inf", and
that library instance is left alone.

The RISC-V OVMF platform uses "BaseIoLibIntrinsic.inf", but RISC-V
already doesn't (can't) use the IA32/X64 NASM files.

So, surprisingly, the "IoFifo.nasm" files are actually unused,
pre-patch; IA32 and X64 OVMF only uses the "IoFifoSev.nasm" files.

Acked-by: Laszlo Ersek 

Thanks!
Laszlo




> 
> Thanks,
> Ray
> 
> *From:* devel@edk2.groups.io  on behalf of duntan
> 
> *Sent:* Thursday, November 9, 2023 10:49 AM
> *To:* devel@edk2.groups.io 
> *Subject:* [edk2-devel] [PATCH 0/2] Remove string IO instruction in
> BaseIoLibIntrinsic.inf
>  
> Simplify IoRead/WriteFifo implement in BaseIoLibIntrinsic by repeatedly
> calling
> IoRead/Write in C code. This can avoid calling assembly code to use
> string I/O instructions.
> With this change, Ia32/IoFifo.nasm and X64/IoFifo.nasm can be removed. Also
> source files for IA32 and X64 are the same.
> 
> Dun Tan (2):
>   MdePkg: Change IoLibFifo.c to IoLibFifoCc.c
>   MdePkg:simplify Fifo API in BaseIoLibIntrinsic
> 
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf    |  10
> ++
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |   2 +-
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c   |  59
> +++
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifoCc.c | 217
> +
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm   | 120
> 
>  6 files changed, 251 insertions(+), 288 deletions(-)
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
>  create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibFifoCc.c
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm
> 
> -- 
> 2.31.1.windows.1
> 
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] TPM2 NVM WRITE IN EDK2

[Laszlo Ersek]

On 11/9/23 11:39, Hamit Can Karaca wrote:
> Hello,
> I am a young UEFI developer and I am trying to use the functions in
> Tpm2CommandLib to write data to TPM2. I have defined the index that, I
> am going to write data to, using the DefineSpace function. But whenever
> I am trying to use the Tpm2NvWrite function, I keep getting
> EFI_DEVICE_ERROR with a response code 0x1D5. Is there anything to do
> before Tpm2NvWrite that I don't know or do I use the wrong parameters?
> If anyone has used these functions please let me know, thanks!

I think this should be possible to explain from the TPM2 spec, part 2,
"structures".

Response code 0x1D5 is binary 111010101. Bit 7 is set, therefore we have
to look at the format-1 RC structure:

  0001 1 1 010101
   - - --
 N F P  E

N=1 (1-based parameter that the error refers to)
F=1 (format-1 response)
P=1 (error is associated with a parameter)
E=0x15 (error number)

In Table 16, RC_FMT1 (value 0x80 -- F bit, or bit 7) says "This bit is
SET in all format 1 response codes. The codes in this group may have a
value added to them to indicate the handle, session, or parameter
to which they apply". Indeed, we have P=1 (error is associated with
parameter) and N=1 (1-based parameter number related to the error is 1).

Thus, we have TPM_RC_SIZE (= RC_FMT1 + 0x015, 0x95, to which we add P=1
(0x40) and N=1 (0x100) for getting 0x1D5):

TPM_RC_SIZE: structure is the wrong size

In other words, whatever command you are sending, the TPM seems to reply
with "parameter 1 of your command is incorrectly sized".

Laszlo



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

Re: [edk2-devel] [PATCH 0/4] Sync BSP's APIC mode to APs in MP init flow

[Laszlo Ersek]

On 11/9/23 19:08, Michael D Kinney wrote:
> +Ray
> 
>  
> 
> Unless I missed it, I do not see review of the patch series Ray sent
> back in July.

Right, please repost.

Laszlo

> 
>  
> 
> Mike
> 
>  
> 
> *From:* devel@edk2.groups.io  *On Behalf Of *Aaron
> Young via groups.io
> *Sent:* Thursday, November 9, 2023 8:29 AM
> *To:* Gerd Hoffmann ; devel@edk2.groups.io
> *Subject:* Re: [edk2-devel] [PATCH 0/4] Sync BSP's APIC mode to APs in
> MP init flow
> 
>  
> 
>  
> 
>  Hello, is this issue/patch still being worked/considered? If so, is
> there an ETA?
> 
>  Without this fix, one cannot hotplug beyond 255 vcpus with OVMF and we
> need this capability.
> 
>  NOTE: Gerd's original fix
> (https://edk2.groups.io/g/devel/message/100801
> ), does allow hotplug
> beyond 255 vcpus. So, that fix seems viable. Should it be re-evaluated?
> 
>  We would gladly test a fix if that would be helpful.
> 
>  Thanks in advance!
> 
>  -Aaron Young (aaron.yo...@oracle.com )
> 
> 



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

[edk2-devel] edk2 uncrustify update (73.0.8)?

[Laszlo Ersek]

Hi Michael,

recently I encountered an uncrustify failure on github.

The reason was that my local uncrustify was *more recent* (73.0.8) than
the one we use in edk2 CI (which is 73.0.3, per the edk2 file
".pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml").

Updating the version number in the YAML file (i.e., advancing edk2 to
version 73.0.8) seems easy enough, but:

- Do you think 73.0.8 is mature enough for adoption in edk2?

  This upstream uncrustify release was tagged in April (and I can't see
  any more recent commits), so I assume it should be stable.

- Would the version update require a whole-tree re-uncrustification?

The reason I'm not just ignoring this topic is that 73.0.8 actually
produces *better output* than 73.0.3, at least in the one instance I
encountered. Compare:

> diff --git 
> a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c 
> b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> index 434cdca84b23..3a6f75988220 100644
> --- a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> +++ b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> @@ -43,12 +43,12 @@ STATIC EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL
>  STATIC CONST EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  mMmio64Configuration = {
>ACPI_ADDRESS_SPACE_DESCRIPTOR,   // Desc
>(UINT16)(// Len
> -   sizeof 
> (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> -   OFFSET_OF (
> - 
> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> - ResType
> - )
> -   ),
> +sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> +OFFSET_OF (
> +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> +  ResType
> +  )
> +),
>ACPI_ADDRESS_SPACE_TYPE_MEM, // ResType
>0,   // GenFlag
>0,   // SpecificFlag
> @@ -77,12 +77,12 @@ STATIC CONST EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  
> mMmio64Configuration = {
>  STATIC CONST EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  mOptionRomConfiguration =   {
>ACPI_ADDRESS_SPACE_DESCRIPTOR,   // Desc
>(UINT16)(// Len
> -   sizeof 
> (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> -   OFFSET_OF (
> - 
> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> - ResType
> - )
> -   ),
> +sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> +OFFSET_OF (
> +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> +  ResType
> +  )
> +),
>ACPI_ADDRESS_SPACE_TYPE_MEM, // ResType
>0,   // GenFlag
>0,   // Disable option roms 
> SpecificFlag

Note that 73.0.3 indents the subexpression to the "//"  comment on the
previous line, while 73.0.8 ignores the comment -- which I think is
justified here.

I believe this improvement may come from uncrustify commit 239c4fad745b
("Prevent endless indentation scenario in struct assignment",
2022-07-29). I think it's worth having in edk2.

CC: stewards, Pedro (commit 6ded9f50c3aa), Marcin (traditionally a big
fan of uncrustify :))

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH v2] MdeModulePkg/PciHostBridgeDxe: Add readback after final Cfg-Write

[Laszlo Ersek]

On 11/8/23 02:06, Michael D Kinney wrote:
> Hi Jose,
> 
>  
> 
>  1. This logic needs to move into an AARCH64 specific directory/file. 
> Other architectures handle this in other ways.
>  2. There are many places throughout edk2 sources that perform PCI
> config write operations.  You are only fixing it in a single
> location.  You may want to look at the MdePkg PciLibs to see if it
> can be addressed there with an AARCH64 specific dir/file, but that
> still may not address all possible PCI config write accesses.  Fill
> analysis of the target platform sources may be required to make sure
> it is fixes for all locations.

Hm.

Perhaps if this change is pushed down as much as possible, into a
special AARCH64 PciLib instance, so that the readback or the DSB (IIRC)
is performed after every PCI config space write, then that might
actually suffice. Because, ultimately, PciHostBridgeDxe too depends on
PciSegmentLib for the access sycles.

(Previously I suggested extending PciHostBridgeLib with a new API, but
that wasn't right, per your second point -- I didn't realize the same
issue must exist (for example) in the PEI phase, before the PCI-related
protocols even exist.)

Laszlo


> 
>  
> 
> Mike
> 
>  
> 
> *From:* Jose Lopez 
> *Sent:* Tuesday, November 7, 2023 10:59 AM
> *To:* devel@edk2.groups.io
> *Cc:* Leif Lindholm ; Ard Biesheuvel
> ; Gao, Liming ;
> Michael Brown ; Pedro Falcato ;
> Ni, Ray ; Wu, Hao A ; Wang, Jian J
> ; Sami Mujawar ;
> ler...@redhat.com; Kinney, Michael D 
> *Subject:* Re: [PATCH v2] MdeModulePkg/PciHostBridgeDxe: Add readback
> after final Cfg-Write
> 
>  
> 
> ++ Laszlo and Michael
> 
>  
> 
> On Tue, Nov 7, 2023 at 10:54 AM Jose Lopez  > wrote:
> 
> ++ CC'd
> 
>  
> 
>  
> 
> On Mon, Nov 6, 2023 at 6:02 PM Joe Lopez  > wrote:
> 
> From: joelopez333 mailto:jlo...@gmail.com>>
> 
>     REF:https://edk2.groups.io/g/devel/topic/102310377#110456
> 
> 
>     Problem Report:
> 
>     On AARCH64, there is no ordering guarantee between configuration
>     space (ECAM) writes and memory space reads (MMIO). ARM AMBA CHI
>     only guarantees ordering for reads and writes within a
> single address region,
>     however, on some systems MMIO and ECAM may be split into
> separate
>     address regions.
> 
>     A problem may arise when an ECAM write is issued a
> completion before a subsequent
>     MMIO read is issued and receives a completion.
> 
>     For example, a typical PCI software flow is the following:
> 
>     1. ECAM write to device command register to enable memory space
>     2. MMIO read from device memory space for which access was
> enabled
>     in step 1.
> 
>     There is no guarantee that step 2. will not begin before the
> completion of step 1.
>     on systems where ECAM/MMIO are specified as separate address
> regions, even
>     if both spaces have the memory attributes device-nGnRnE.
> 
>     Fix:
> 
>     - Add a read after the final PCI Configuration space write
>       in RootBridgeIoPciAccess.
> 
>     - When configuration space is strongly ordered, this ensures
>       that program execution cannot continue until the completion
>       is received for the previous Cfg-Write, which may have
> side-effects.
> 
>     - Risk of reading a "write-only" register and causing a CA
> which leaves the device
>       unresponsive. The expectation based on the PCI Base Spec
> v6.1 section 7.4 is that
>       all PCI Spec-defined registers will be readable, however,
> there may exist
>       design-specific registers that fall into this category.
> 
>     Cc: Leif Lindholm  >
>     Cc: Ard Biesheuvel  >
>     Cc: Sami Mujawar  >
>     Cc: Jian J Wang  >
>     Cc: Liming Gao  >
>     Cc: Hao A Wu mailto:hao.a...@intel.com>>
>     Cc: Ray Ni mailto:ray...@intel.com>>
>     Cc: Pedro Falcato  >
>     Cc: Michael Brown mailto:mc...@ipxe.org>>
>     Signed-off-by: Joe Lopez  >
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 8
> 
>  1 file changed, 8 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>

Re: [edk2-devel] [PATCH v1] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

[Laszlo Ersek]

On 11/8/23 05:11, Wu, Jiaxin wrote:
> Hi Laszlo,
> 
>>>
>>> The patch looks OK to me, but:
>>>
>>> - I would like to test it with CPU hotplug (later, likely under v2), and
>>>
> 
> Sure, I can wait the update from you.
> 
>>> - I think this should be two patches.
>>>
>>> First, the SmmAddProcessor() function should be extended just to
>>> complete commit 1fadd18d. (BTW I highly appreciate the reference to
>>> commit 1fadd18d; otherwise I couldn't find where the *coldplugged* CPUs'
>>> locations were retrieved!)
>>>
>>> Then the Package calculations should be updated separately -- mostly
>>> because I would appreciate a concrete description in that separate
>>> commit message why the difference matters. Clearly you have a use case
>>> where the v1 and v2 package numbers differ, and recording that in the
>>> commit history would be great.
> 
> Sure, let me explain more, there are 2 reason I did this change:
> 
> 1. the processor package ID retrieved from CPUID 0x0Bh may be not 
> correct/accurate if CPU has the module & die info, it depends on the CPUID 
> implementation. See SDM statement:
> 
> EAX Bits 04 - 00: Number of bits to shift right on x2APIC ID to get a unique 
> topology ID of the *next level type*
> ECX Bits 15 - 08: *Level type*
> Level type field has the following encoding:
> 0: Invalid.
> 1: SMT.
> 2: Core.
> 3-255: Reserved
> 
> So,  if level type returned from ECX Bits 15 - 08 is 2 (Core), then what's 
> the next level mean? Module or Die or Package? SDM doesn't has explanation 
> for the next level of Core. If so, the value will be decided by 
> implementation. 
> The value can be package info for compatibility consideration, but it's not 
> standardized. That's the reason we suggest use the leaf 1Fh.
>
> 2. And according SDM declaration, "CPUID leaf 1FH is a preferred superset to 
> leaf 0BH. Intel recommends first checking for the existence of CPUID leaf 1FH 
> before using leaf 0BH."
> This is perfect match the existing GetProcessorLocation2ByApicId() 
> implementation. 
> 
> That's the main reasons we switch to EFI_CPU_PHYSICAL_LOCATION2.
> 
>>
>> Side note, just for completeness: the x2apic lib instance performs the
>> v2 feature detection correctly since Gerd's commit 170d4ce8e90a
>> ("UefiCpuPkg/BaseXApicX2ApicLib: fix CPUID_V2_EXTENDED_TOPOLOGY
>> detection", 2023-10-25). Furthermore, OVMF uses the x2apic lib instance
>> since commit decb365b0016 ("OvmfPkg: select LocalApicLib instance with
>> x2apic support", 2015-11-30). Therefore, this patch looks fine for OVMF.
>>
>> However, for platforms that use the old xapic lib instance, there could
>> be problems, as the v2 feature detection in *that* instance is not fixed
>> -- it does not check EBX.
>>
> 
> Great catch this! I can create the patch 3 for this porting to old xapic lib 
> instance if you no objection.

Sure, sounds good, although I have no way of testing that.

Laszlo



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

Re: [edk2-devel] [PATCH v2 4/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix NULL_RETURNS Coverity issue

[Laszlo Ersek]

On 11/10/23 07:11, Ranbir Singh wrote:
> EFI_NOT_READY was listed as one of the error return values in the
> function header of StartPciDevices(). So, I considered it here.
> 
> Maybe we can go by a dual approach, including CpuDeadLoop() in
> StartPciDevices() as well as add return value check at the call site in
> PciBusDriverBindingStart().

I don't think this makes much sense, given that execution is not
supposed to continue past CpuDeadLoop(), so the new error check would
not be reached.

I think two options are realistic:

- replace the assert() with a CpuDeadLoop() -- this is my preference

- keep the assert, add the "if", and in the caller, handle the
EFI_NOT_READY error. This is workable too. (Keeping the assert is goog
because it shows that we don't expect the "if" to fire.)

Anyway, now that we have no way to verify the change against Coverity, I
don't know if this patch is worth the churn. :( As I said, this ASSERT()
is one of those few justified ones in edk2 core that can indeed never
fail, IMO.

Laszlo


> 
> On Tue, Nov 7, 2023 at 10:18 PM Laszlo Ersek  <mailto:ler...@redhat.com>> wrote:
> 
> On 11/7/23 07:19, Ranbir Singh wrote:
> > From: Ranbir Singh 
> >
> > The function StartPciDevices has a check
> >
> >     ASSERT (RootBridge != NULL);
> >
> > but this comes into play only in DEBUG mode. In Release mode, there
> > is no handling if the RootBridge value is NULL and the code proceeds
> > to unconditionally dereference "RootBridge" which will lead to CRASH.
> >
> > Hence, for safety add NULL pointer checks always and return
> > EFI_NOT_READY if RootBridge value is NULL which is one of the return
> > values as mentioned in the function description header.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> <https://bugzilla.tianocore.org/show_bug.cgi?id=4239>
> >
> > Cc: Ray Ni mailto:ray...@intel.com>>
> > Co-authored-by: Veeresh Sangolli  <mailto:veeresh.sango...@dellteam.com>>
> > Signed-off-by: Ranbir Singh 
> > Signed-off-by: Ranbir Singh  <mailto:rsi...@ventanamicro.com>>
> > ---
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > index 581e9075ad41..3de80d98370e 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > @@ -772,7 +772,10 @@ StartPciDevices (
> >    LIST_ENTRY     *CurrentLink;
> > 
> >    RootBridge = GetRootBridgeByHandle (Controller);
> > -  ASSERT (RootBridge != NULL);
> > +  if (RootBridge == NULL) {
> > +    return EFI_NOT_READY;
> > +  }
> > +
> >    ThisHostBridge = RootBridge->PciRootBridgeIo->ParentHandle;
> > 
> >    CurrentLink = mPciDevicePool.ForwardLink;
> 
> I don't think this is a good fix.
> 
> There is one call site, namely in PciBusDriverBindingStart(). That call
> site does not check the return value. (Of course /s)
> 
> I think that this ASSERT() can indeed never fail. Therefore I suggest
> CpuDeadLoop() instead.
> 
> If you insist that CpuDeadLoop() is "too risky" here, then the patch is
> acceptable, but then the StartPciDevices() call site in
> PciBusDriverBindingStart() must check the error properly: we must not
> install "gEfiPciEnumerationCompleteProtocolGuid", and the function must
> propagate the error outwards.
> 
> Laszlo
> 



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

Re: [edk2-devel] [PATCH v2 2/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix MISSING_BREAK Coverity issues

[Laszlo Ersek]

On 11/8/23 05:29, Ranbir Singh wrote:
> Hi Mike,
> 
> I agree that any manual inspection is sort of a burden, more so when it
> becomes repetitive in the long run.
> 
> When I was doing these Coverity checks (Nov-Dec' 2022), I was working in
> Dell and had access to the real systems to check the execution flow as
> well as the Coverity status. I could never post these patches while
> being there, but happened to raise Bugzilla's and post them there
> instead hoping that they would be taken up by somebody further.
> 
> I am no longer with Dell and later on when I found that those BZ /
> issues pointed out by Coverity still exist as there are no code changes
> in related contexts, I thought of taking them forward in whatever
> limited capacity I can. I am a bit hesitant to do any further code
> changes as now I do not have any systems to check the execution flow as
> well as the Coverity status. So, I do not guarantee, but will try to
> make the code changes wherever it is easy to ascertain that the
> functional flow would not be impacted and the same issue won't exist
> anymore.

This makes me a bit sad.

I was happy to see that a company seriously invested in cleaning up
Coverity issue reports all over edk2.

If you don't have the environment and/or the assignment to continue
doing that, then I agree that further tweaking these patches is
unjustifed. (Sorry, I didn't realize the background when I reviewed your
patches.) New versions would effectively mean "untested" code (untested
as in not tested with Coverity specifically). In particular because the
purported warning fixes will require real edk2 review (and occasionally
regression testing even), which doesn't look good if we can't even be
sure that the change actually placates coverity.

I guess we should upstream those of your patches that are fine right as
they are, and drop the rest for now. (A pity!) Accordingly, if you think
some of my review comments are not especially important in this light
(i.e., whenever it is better to take the patch as is, than to drop an
updated version due to untestability), then please do comment so explicitly!

Laszlo



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

Re: [edk2-devel] [PATCH v2 24/30] OvmfPkg/LoongArchVirt: Add platform boot manager library

[Laszlo Ersek]

On 11/10/23 10:46, Gerd Hoffmann wrote:
> On Fri, Nov 10, 2023 at 03:09:47PM +0800, Chao Li wrote:
>> Hi Laszlo,
>>
>> Sorry, I'm not check carefully, it is really **copied**, and we not think
>> the ARM version is not good enough.
>>
>> So, can I move this library to OvmfPkg so other ARCH use it easily?
> 
> Moving code from ArmVirtPkg to OvmfPkg is fine.
> 
> OvmfPkg is the home for both x86 virtual machine bits and shared code.
> The later used to be mostly virtio drivers, but with the arrival of
> riscv some fdt support code has already moved from ArmVirtPkg to OvmfPkg
> so arm and riscv can share it.  Doing the same for loongarch is
> perfectly fine.

Agreed!

The naming of course remains tricky. :) It's not easy to come up with
good names for distinguishing various instances of the same library class.

I suggest renaming "OvmfPkg/PlatformBootManagerLib" to
"PlatformBootManagerLibX86", and calling ArmVirtPkg's instance (once
moved) PlatformBootManagerLibGeneric or just PlatformBootManagerLib.

Laszlo



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

Re: [edk2-devel] [PATCH v2 23/30] OvmfPkg/LoongArchVirt: Add PeiServiceTablePointerLib

[Laszlo Ersek]

On 11/10/23 07:44, Chao Li wrote:
> Hi Laszlo,
> 
> This is a good question, same as the previous email, some ARCH don't
> require running code on memory during PEI phase or other reason can not
> used the MdePkg version, so this pointer will be saved by some register,
> I saw the ArmPkg version also uses a register to save this pointer.
> 
> If I move ArmPkg version PeiServiceTablePointer to MdePkg and the method
> of getting and saving the pointer use a new library which related
> architecture, other word, the API of PeiServiceTablePointer has not
> changed, adding a new library that PeiServiceTablePointer depends on,
> the real saving and reading method completed in the new library. Do you
> think this way is better?

Right. I think you need a loongarch-specific library instance of
PeiServicesTablePointerLib under MdePkg. Presumably, if / when you
enable edk2 on *physical* loongarch platforms, you're going to need the
same library instance. And therefore it should not be under OvmfPkg, but
MdePkg.

In fact, now that I'm reading the comments in
"MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c",
it seems that the architecture bindings in the Platform Init
specification actually document how the PEI services table pointer is
supposed to be stored before system memory becomes available (IIUC).

The latest version of the PI spec that I have is 1.8.

In Volume I, there is a section titled "I-9.4 PEI Services Table
Retrieval". It considers the following architectures: X86, x64, Itanium,
ARM, AArch64, RISC-V.

I think that in the longer term, you should file a PIWG Mantis ticket
for extending this section, with an Engineering Change Request where you
describe how this mechanism should work on loongarch.

And then the implementation certainly belongs to MdePkg.

(Note that I'm *not* saying you should first update the specification
and then implement it in edk2 -- that's not my point. My point is that
*eventually*, this mechanism will become a part of the public loongarch
bindings, and therefore you can already start introducing it under
MdePkg, in my opinion anyway.)

Note that "prior art" is inconsistent here, regarding edk2 locations,
because, as you say, the arm/aarch64 implementation lives under ArmPkg
-- but it's quite unlikely IMO that a LoongArchPkg top-level directory
would be introduced. In the longer term, we might want to consolidate
all PeiServicesTablePointerLib instances under MdePkg.


Then your question is, IIUC, whether to reuse any portion of the ArmPkg
implementation. I don't think that's necessary; the library is so small,
there is effectively *nothing generic* in it. Put differently, all of it
is architecture specific. Thus I think you can just add a totally
self-contained loongarch instance.

Laszlo



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

Re: [edk2-devel] [PATCH v2 20/30] OvmfPkg/LoongArchVirt: Add serial port library

[Laszlo Ersek]

On 11/10/23 05:51, Chao Li wrote:
> Hi Laszlo,
> 
> Sorry, it is my fault, I should separate this this patch for two
> standalone patches, and with some detailed commit message. I will fix
> this in V3.
> 
> Currently, there are two libraries are not independent, so I guess you
> are talking about Fdt16550SerialPortHookLib. I would say that the
> different is not in GetSerialConsolePortAddress, the logic about this
> function is same to ARM, the different is in
> PlatformHookSerialPortInitialize. Since some platform do not require
> running code on memory during the PEI phase, so the ARM version of
> PlatformHookSerialPortInitialize will use PcdSet to set a PCD value, if
> the memory is not ready, this funciton can not be used. So this library
> is override from ArmVirtPkg to LongArchVirt. 
> 
> BTW, the new library FdtSerialProtAddressLib which you committed a few
> days ago, I will look into it and try it. Roughly speaking, it is look
> like the code for obtaining the serial port address is sparated from the
> HookLIb. I have a question, can I move this library to OvmfPkg so that
> other ARCH can use it easily?

Yes, I think that's consistent with earlier code movements. Moving code
from ArmVirtPkg to OvmfPkg for improving (or enabling) code reuse is
valid, because ArmVirtPkg can continue consuming the same code from OvmfPkg.

> 
> Regarding FdtSerialPortAddressLib, I would like to say that it was not
> committed when I porting LoongArchVirt,  my code base is based on
> stable202308, so I don't know you committed a new library, sorry.

Sure, that sometimes happens when a new feature takes long (either to
implement, or to review).

Laszlo

> 
> 
> 
> Thanks,
> Chao
> 在 2023/11/9 06:21, Laszlo Ersek 写道:
>> On 11/7/23 11:12, Chao Li wrote:
>>> Hi Gerd,
>>>
>>> These two libraries is not only copy code, the way of obtain the serial
>>> base address is different from ARM, and the early serial port output
>>> also different from ARM, so these two libraries are LoongArch specific.
>> I think we're going to have to go through the design with "baby steps".
>>
>> The commit message of the patch is empty.
>>
>> Please don't expect reviewers to "reverse engineer" the design from the
>> code. That's hugely taxing. It's hard enough to review code when we
>> precisey know in advance, from the commit message, what the code will
>> try to achieve.
>>
>> You are saying that the way to obtain serial base address is different
>> from ARM, yet the GetSerialConsolePortAddress() function looks very
>> similar to the function that I *replaced* in recent commits eb83b5330961
>> ("ArmVirtPkg: introduce FdtSerialPortAddressLib", 2023-10-26) and
>> f078a6fdd4d7 ("ArmVirtPkg/Fdt16550SerialPortHookLib: rebase to
>> FdtSerialPortAddressLib", 2023-10-26).
>>
>> So there are two issues with your GetSerialConsolePortAddress() function
>> immediately, I would say:
>>
>> - you say that it's different from ARM, but it seems to parse the DTB
>> identically (or mostly identically -- I'm speaking from memory),
>>
>> - I factored out the subject DTB parsing logic in the above-noted
>> commits recently, so even if your GetSerialConsolePortAddress() function
>> is *supposed* to parse the DTB identically to ARM, then the way to
>> employ that logic is different; it should be reused, not duplicated.
>>
>> Now that you have a running prototype (basically evidence that the port
>> to this new architecture can be done), can we go through the design of
>> each component (library, driver etc) one by one? Dumping the whole thing
>> on reviewers all at once, with little documentation, is not helpful. We
>> basically need to start with the specification of each of your modules.
>> See where the existing components in edk2 are not good enough or not
>> flexible enough, etc.
>>
>> Laszlo



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

Re: [edk2-devel] [PATCH v1 3/7] UefiCpuPkg: Adds SmmCpuSyncLib library class

[Laszlo Ersek]

On 11/13/23 04:15, Ni, Ray wrote:
> I provided 4 comments in below, starting with "[Ray".
> 
> Sorry for the poor new Outlook that I am not able to put ">" in the
> original email.
> 
> Thanks,
> Ray
> 
> 
> 
> (1) I agree that the internals of the context should be hidden, but
> (VOID*) is not the right way. Instead, please use an incomplete
> structure type.
> 
> That is, in the library header class file, do the following:
> 
>   typedef struct SMM_CPU_SYNC_CTX SMM_CPU_SYNC_CTX;
> 
> and then make all these functions return and take
> 
>   SMM_CPU_SYNC_CTX *
> 
> The library users will still not know what is inside SMM_CPU_SYNC_CTX,
> just like with (VOID*), but the compiler will be able to perform much
> stronger type checking than with (VOID*).
> 
> And then in the library *instance(s)*, you can complete the incomplete type:
> 
>   struct SMM_CPU_SYNC_CTX {
>     ...
>   };
> 
> [Ray.1] Good suggestion. I still remember you taught me this technique
> when I
> wrote the FrameBufferBltLib.
> 
> (3) By definition, in a function that resets the internals of an object,
> you cannot specify "IN" for that function. It must be OUT.
> 
> [Ray.2] I have a different opinion about IN/OUT.  I think we should use
> "IN OUT".

OK! I can see that "reset" may rely on previous information in the
structure. Furthermore, "IN OUT" may indeed better reflect the
requirement that the object being reset must have been initialized
previously (i.e. that it must be a valid object at the time of the
"reset" call).

> 
> 
> Please add a large comment to the top of the library class header that
> explains the operation / concepts of the context. What operations and
> behaviors are defined for this data type?
> 
> [Ray.3] Good suggestions.
> The lib provides 3 sets of APIs:
> 1. Init/Deinit
> Init() is called in driver's entrypoint for allocating the storage and
> initialize the content of sync object.
> Deinit() is called in driver's unload function for undoing what has been
> done in Init().
> 
> 2. CheckInCpu/CheckOutCpu/LockDoor/GetArrivedCpuCount
> When SMI happens, all processors including BSP enter to SMM mode by
> calling CheckInCpu().
> The elected BSP calls LockDoor() so that CheckInCpu() after that returns
> failure code.
> CheckOutCpu() is called in error handling flow for the CPU who calls
> CheckInCpu() earlier.
> GetArrivedCpuCount() returns the number of checked-in CPUs.
> 
> 3. WaitForAllAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp
> First 2 APIs are called from BSP.
> Latter 2 APIs are called from APs.
> The 4 APIs are used to synchronize the running flow among BSP and APs.

This sounds really nice in fact; I'd be glad to see it captured in the
comments!

> 
>> +
>> +  @return CPU arrival count number.
> 
> (14) why is it necessary for outputting the arrived number when locking?
> [Ray.4] As I explained above, when BSP locks the door, it might need to
> know how many CPUs are in the SMM "room".
> Maybe today the number is not cared by BSP.
> 

This helps, thanks. Please do capture it in the comments.

Laszlo



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

Re: [edk2-devel] [edk2-platforms PATCH 1/2] WhitleyOpenBoardPkg: remove references

[Laszlo Ersek]

Hi Chasel,

On 11/10/23 02:13, Chiu, Chasel wrote:
> 
> Hi Laszlo,
> 
> I verified and encountered build failure as some files still consuming 
> definitions from LegacyBiosMpTable.h, for example:
> https://github.com/tianocore/edk2-platforms/blob/899a9dc97cd54690513380ad01ee8b2609dbefd5/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.c#L22
> 
> Any suggestion that we can reduce impact to existing platforms?

thanks for testing the build!

Here's my problem: this information seems to be exposed
firmware-globally, ultimately. We have a UbaConfigProtocol->AddData()
call, which exposes SystemBoardInfoData. SystemBoardInfoData exposes
SystemBoardInfoCallback(). That one in turn exposes SystemBoardInfoTable
(of type DXE_SYSTEM_BOARD_INFO).

And so on and so on, and ultimately we publicly expose
DEVICE_DATA_HW_LOCAL_INT.

That structure type is defined in
"Platform/Intel/WhitleyOpenBoardPkg/Include/PlatDevData.h", and it only
has the following comment:

"Platform hardwired data describing connection of interrupt sources to
local APICs"

So I can't tell if this structure type officially and explicitly defers
to the MP Table specification, or just ad-hoc reuses the same values.

In the former case, we cannot remove LegacyBiosMpTable.h from edk2 (or
perhaps we need to move it over to edk2-platforms).

In the latter case, we should just replace the enum constants with their
integer values (or perhaps replace them with some different macros, like
ACPI spec macros or similar), and then we can delete LegacyBiosMpTable.h.

That is, we need to figure out where the DEVICE_DATA_HW_LOCAL_INT type
definition originates from.

The particular "DeviceDataHwLocalInt1" array comes from edk2-platforms
commit 3584efd25110 ("WhitleyOpenBoardPkg: Add UBA Modules",
2021-07-14). The commit message is empty -- so it's a dead-end.

The type definition comes from edk2-platforms commit 41bfa85f527a
("WhitleyOpenBoardPkg: Add Includes and Libraries", 2021-07-14). The
commit message is similarly empty.

Laszlo

> 
> Thanks,
> Chasel
> 
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Thursday, November 9, 2023 4:06 AM
>> To: devel@edk2.groups.io
>> Cc: Chaganty, Rangasai V ; Desimone, Nathaniel
>> L ; Chiu, Chasel 
>> Subject: [edk2-devel] [edk2-platforms PATCH 1/2] WhitleyOpenBoardPkg:
>> remove  references
>>
>> For removing "MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h" from
>> edk2, first remove the edk2-platforms references to that header file.
>>
>> I can't build-test this change. As far as I can tell, building the 
>> CooperCityRvp and
>> WilsonCityRvp platforms with "build_bios.py" should build these changes;
>> however, both platforms fail to build without FSP blobs.
>>
>> I think there's a fair chance that this patch should work nonetheless;
>>  introduces names prefixed with
>> EFI_LEGACY_MP_TABLE_, and edk2-platforms doesn't contain that string. (The
>> one exception is FEATUREBYTE2_5, which is also absent from edk2-platforms.)
>>
>> Cc: Sai Chaganty 
>> Cc: Nate DeSimone 
>> Cc: Chasel Chiu 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1754
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoar
>> dInfoDxe/SystemBoardInfoDxe.h | 1 -
>>
>> Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/Platform
>> DeviceDataSRP10nm.c   | 1 -
>>  2 files changed, 2 deletions(-)
>>
>> diff --git
>> a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBo
>> ardInfoDxe/SystemBoardInfoDxe.h
>> b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBo
>> ardInfoDxe/SystemBoardInfoDxe.h
>> index 32c16ff9110a..d8c209a57f75 100644
>> ---
>> a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBo
>> ardInfoDxe/SystemBoardInfoDxe.h
>> +++
>> b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBo
>> +++ ardInfoDxe/SystemBoardInfoDxe.h
>> @@ -27,7 +27,6 @@
>>  #include 
>>  #include 
>>
>> -#include 
>>  #include 
>>
>>  #endif  //_SYSTEM_BOARD_INFO_DXE_H_
>> diff --git
>> a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/Platfor
>> mDeviceDataSRP10nm.c
>> b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/Platfor
>> mDeviceDataSRP10nm.c
>> index ed9f80734cd7..b69ae1736bb8 100644
>> ---
>> a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/Platfor
>> mDeviceDataSRP10nm.c
&g

[edk2-devel] [PATCH 36/37] OvmfPkg: remove Pcd8259LegacyModeEdgeLevel and Pcd8259LegacyModeMask

[Laszlo Ersek]

The following PCDs are unused at this point; remove them:

- Pcd8259LegacyModeEdgeLevel
- Pcd8259LegacyModeMask

This shrinks the list of resources scheduled for removal to nil.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Michael Roth 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec  | 26 
 OvmfPkg/AmdSev/AmdSevX64.dsc |  3 ---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc |  3 ---
 OvmfPkg/Microvm/MicrovmX64.dsc   |  3 ---
 OvmfPkg/OvmfPkgIa32.dsc  |  3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc   |  3 ---
 OvmfPkg/OvmfPkgX64.dsc   |  3 ---
 OvmfPkg/OvmfXen.dsc  |  3 ---
 8 files changed, 47 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 2e9e699aa6ab..b44fa039f76c 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -256,32 +256,6 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
 
-  ## Pcd8259LegacyModeMask defines the default mask value for platform. This
-  #  value is determined.
-  #  1) If platform only support pure UEFI, value should be set to 0x or
-  # 0xFFFE; Because only clock interrupt is allowed in legacy mode in pure
-  # UEFI platform.
-  #  2) If platform install CSM and use thunk module:
-  # a) If thunk call provided by CSM binary requires some legacy interrupt
-  #support, the corresponding bit should be opened as 0.
-  #For example, if keyboard interfaces provided CSM binary use legacy
-  #keyboard interrupt in 8259 bit 1, then the value should be set to
-  #0xFFFC.
-  # b) If all thunk call provied by CSM binary do not require legacy
-  #interrupt support, value should be set to 0x or 0xFFFE.
-  #
-  #  The default value of legacy mode mask could be changed by
-  #  EFI_LEGACY_8259_PROTOCOL->SetMask(). But it is rarely need change it
-  #  except some special cases such as when initializing the CSM binary, it
-  #  should be set to 0x to mask all legacy interrupt. Please restore the
-  #  original legacy mask value if changing is made for these special case.
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask|0x|UINT16|0x3
-
-  ## Pcd8259LegacyModeEdgeLevel defines the default edge level for legacy
-  #  mode's interrrupt controller.
-  #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x5
-
   gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
   gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
 
diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a00f4c12904c..f416193984f6 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -460,9 +460,6 @@ [PcdsFixedAtBuild]
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100
 
-  # IRQs 5, 9, 10, 11 are level-triggered
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
-
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index af0ecb0453ea..152d05b52c3d 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -457,9 +457,6 @@ [PcdsFixedAtBuild]
 
   gEfiShellPkgTokenSpaceGuid.PcdShellFileOperationSize|0x2
 
-  # IRQs 5, 9, 10, 11 are level-triggered
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
-
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 75c53c0bb287..b538c234cf2b 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -555,9 +555,6 @@ [PcdsFixedAtBuild]
 
   gEfiShellPkgTokenSpaceGuid.PcdShellFileOperationSize|0x2
 
-  # IRQs 5, 9, 10, 11 are level-triggered
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
-
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 8021c2f325f3..361fdec7a8c1 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -580,9 +580,6 @@ [PcdsFixedAtBu

[edk2-devel] [PATCH 37/37] OvmfPkg: remove CSM_ENABLE build macro

[Laszlo Ersek]

At this point, the CSM_ENABLE conditionals only bracket the !error
directives that we added at the front of this series; it's time to remove
CSM_ENABLE.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc   | 7 +--
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 3 ---
 OvmfPkg/OvmfPkgIa32.dsc  | 3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc   | 3 ---
 OvmfPkg/OvmfPkgX64.dsc   | 3 ---
 OvmfPkg/OvmfXen.dsc  | 3 ---
 6 files changed, 1 insertion(+), 21 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 85ad6b194c91..7004f00c69db 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -662,12 +662,7 @@ [Components]
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
   MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
-  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
-
-!ifdef $(CSM_ENABLE)
-!error "CSM is being torn down"
-!endif
-  }
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   MdeModulePkg/Logo/LogoDxe.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {
 
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 152d05b52c3d..aaf8cc6b5dca 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -375,9 +375,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!ifdef $(CSM_ENABLE)
-!error "CSM is being torn down"
-!endif
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootSupported|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdRequireSelfSignedPk|TRUE
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 361fdec7a8c1..135275a01f32 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -470,9 +470,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!ifdef $(CSM_ENABLE)
-!error "CSM is being torn down"
-!endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugSupport|TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 4e362600ff8d..fda01a71ab33 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -477,9 +477,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!ifdef $(CSM_ENABLE)
-!error "CSM is being torn down"
-!endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugSupport|TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 07592a775895..10cd51f41dbf 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -496,9 +496,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!ifdef $(CSM_ENABLE)
-!error "CSM is being torn down"
-!endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugSupport|TRUE
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 9548ffb9482c..19db45c9e996 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -362,9 +362,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!ifdef $(CSM_ENABLE)
-!error "CSM is being torn down"
-!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE


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

[edk2-devel] [PATCH 35/37] OvmfPkg: remove gEfiLegacy8259ProtocolGuid

[Laszlo Ersek]

At this point, gEfiLegacy8259ProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- PCDs:
  - Pcd8259LegacyModeEdgeLevel
  - Pcd8259LegacyModeMask

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec   |   1 -
 OvmfPkg/Include/Protocol/Legacy8259.h | 290 
 2 files changed, 291 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 9d326e8143eb..2e9e699aa6ab 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -181,7 +181,6 @@ [Protocols]
   gXenBusProtocolGuid   = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
   gXenIoProtocolGuid= {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
   gIoMmuAbsentProtocolGuid  = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
-  gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
   gOvmfLoadedX86LinuxKernelProtocolGuid = {0xa3edc05d, 0xb618, 0x4ff6, {0x95, 
0x52, 0x76, 0xd7, 0x88, 0x63, 0x43, 0xc8}}
   gOvmfSevMemoryAcceptanceProtocolGuid  = {0xc5a010fe, 0x38a7, 0x4531, {0x8a, 
0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49}}
   gQemuAcpiTableNotifyProtocolGuid  = {0x928939b2, 0x4235, 0x462f, {0x95, 
0x80, 0xf6, 0xa2, 0xb2, 0xc2, 0x1a, 0x4f}}
diff --git a/OvmfPkg/Include/Protocol/Legacy8259.h 
b/OvmfPkg/Include/Protocol/Legacy8259.h
deleted file mode 100644
index 233e817c0696..
--- a/OvmfPkg/Include/Protocol/Legacy8259.h
+++ /dev/null
@@ -1,290 +0,0 @@
-/** @file
-  This protocol abstracts the 8259 interrupt controller. This includes
-  PCI IRQ routing needed to program the PCI Interrupt Line register.
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  This protocol is defined in Framework for EFI Compatibility Support Module 
spec
-  Version 0.97.
-
-**/
-
-#ifndef _EFI_LEGACY_8259_H_
-#define _EFI_LEGACY_8259_H_
-
-#define EFI_LEGACY_8259_PROTOCOL_GUID \
-  { \
-0x38321dba, 0x4fe0, 0x4e17, {0x8a, 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 
0xc1 } \
-  }
-
-typedef struct _EFI_LEGACY_8259_PROTOCOL EFI_LEGACY_8259_PROTOCOL;
-
-typedef enum {
-  Efi8259Irq0,
-  Efi8259Irq1,
-  Efi8259Irq2,
-  Efi8259Irq3,
-  Efi8259Irq4,
-  Efi8259Irq5,
-  Efi8259Irq6,
-  Efi8259Irq7,
-  Efi8259Irq8,
-  Efi8259Irq9,
-  Efi8259Irq10,
-  Efi8259Irq11,
-  Efi8259Irq12,
-  Efi8259Irq13,
-  Efi8259Irq14,
-  Efi8259Irq15,
-  Efi8259IrqMax
-} EFI_8259_IRQ;
-
-typedef enum {
-  Efi8259LegacyMode,
-  Efi8259ProtectedMode,
-  Efi8259MaxMode
-} EFI_8259_MODE;
-
-/**
-  Get the 8259 interrupt masks for Irq0 - Irq15. A different mask exists for
-  the legacy mode mask and the protected mode mask. The base address for the 
8259
-  is different for legacy and protected mode, so two masks are required.
-
-  @param  This  The protocol instance pointer.
-  @param  MasterBaseThe base vector for the Master PIC in the 8259 
controller.
-  @param  SlaveBase The base vector for the Slave PIC in the 8259 
controller.
-
-  @retval EFI_SUCCESS   The new bases were programmed.
-  @retval EFI_DEVICE_ERROR  A device error occurred programming the vector 
bases.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_LEGACY_8259_SET_VECTOR_BASE)(
-  IN EFI_LEGACY_8259_PROTOCOL   *This,
-  IN  UINT8 MasterBase,
-  IN  UINT8 SlaveBase
-  );
-
-/**
-  Get the 8259 interrupt masks for Irq0 - Irq15. A different mask exists for
-  the legacy mode mask and the protected mode mask. The base address for the 
8259
-  is different for legacy and protected mode, so two masks are required.
-
-  @param  This  The protocol instance pointer.
-  @param  LegacyMaskBit 0 is Irq0 - Bit 15 is Irq15.
-  @param  LegacyEdgeLevel   Bit 0 is Irq0 - Bit 15 is Irq15.
-  @param  ProtectedMask Bit 0 is Irq0 - Bit 15 is Irq15.
-  @param  ProtectedEdgeLevelBit 0 is Irq0 - Bit 15 is Irq15.
-
-  @retval EFI_SUCCESS   8259 status returned.
-  @retval EFI_DEVICE_ERROR  Error reading 8259.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_LEGACY_8259_GET_MASK)(
-  IN EFI_LEGACY_8259_PROTOCOL   *This,
-  OUT UINT16*LegacyMask  OPTIONAL,
-  OUT UINT16*LegacyEdgeLevel  OPTIONAL,
-  OUT UINT16*ProtectedMask  OPTIONAL,
-  OUT UINT16*ProtectedEdgeLevel OPTIONAL
-  );
-
-/**
-  Set the 8259 interrupt masks for Irq0 - Irq15. A different mask exists for
-  the legacy mode mask and the protected mode mask. The base address for the 
8259
-  is different for legacy

[edk2-devel] [PATCH 34/37] OvmfPkg: remove 8259InterruptControllerDxe

[Laszlo Ersek]

8259InterruptControllerDxe is not used by any platforms at this point,
remove it.

This patch removes mentions of the following CSM resources from the source
code:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid

- headers:
  - Protocol/Legacy8259.h

- PCDs:
  - Pcd8259LegacyModeEdgeLevel
  - Pcd8259LegacyModeMask

which extends the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid

- headers:
  - Protocol/Legacy8259.h

- PCDs:
  - Pcd8259LegacyModeEdgeLevel
  - Pcd8259LegacyModeMask

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  16 -
 OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  14 -
 OvmfPkg/8259InterruptControllerDxe/8259.inf|  45 --
 OvmfPkg/8259InterruptControllerDxe/8259.h  | 218 ---
 OvmfPkg/8259InterruptControllerDxe/8259.c  | 622 

 5 files changed, 915 deletions(-)

diff --git a/OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni 
b/OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni
deleted file mode 100644
index d03529241958..
--- a/OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni
+++ /dev/null
@@ -1,16 +0,0 @@
-// /** @file
-// 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
-//
-// 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
-//
-// Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-
-#string STR_MODULE_ABSTRACT #language en-US "8259 Interrupt 
Controller driver that provides Legacy 8259 protocol"
-
-#string STR_MODULE_DESCRIPTION  #language en-US "8259 Interrupt 
Controller driver that provides Legacy 8259 protocol."
-
diff --git a/OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni 
b/OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni
deleted file mode 100644
index ee43f6923c45..
--- a/OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni
+++ /dev/null
@@ -1,14 +0,0 @@
-// /** @file
-// Legacy8259 Localized Strings and Content
-//
-// Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-#string STR_PROPERTIES_MODULE_NAME
-#language en-US
-"Legacy 8259 Interrupt Controller DXE Driver"
-
-
diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
b/OvmfPkg/8259InterruptControllerDxe/8259.inf
deleted file mode 100644
index 7320ff2490a7..
--- a/OvmfPkg/8259InterruptControllerDxe/8259.inf
+++ /dev/null
@@ -1,45 +0,0 @@
-## @file
-# 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
-#
-# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
-# SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = Legacy8259
-  MODULE_UNI_FILE= Legacy8259.uni
-  FILE_GUID  = 245CB4DA-8E15-4A1B-87E3-9878FFA07520
-  MODULE_TYPE= DXE_DRIVER
-  VERSION_STRING = 1.0
-  ENTRY_POINT= Install8259
-
-[Sources]
-  8259.c
-  8259.h
-
-[Packages]
-  MdePkg/MdePkg.dec
-  OvmfPkg/OvmfPkg.dec
-
-[LibraryClasses]
-  UefiBootServicesTableLib
-  DebugLib
-  UefiDriverEntryPoint
-  IoLib
-  PcdLib
-
-[Protocols]
-  gEfiLegacy8259ProtocolGuid## PRODUCES
-  gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
-
-[Pcd]
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask  ## CONSUMES
-  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel ## CONSUMES
-
-[Depex]
-  TRUE
-
-[UserExtensions.TianoCore."ExtraFiles"]
-  Legacy8259Extra.uni
diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.h 
b/OvmfPkg/8259InterruptControllerDxe/8259.h
deleted file mode 100644
index 066552ca933e..
--- a/OvmfPkg/8259InterruptControllerDxe/8259.h
+++ /dev/null
@@ -1,218 +0,0 @@
-/** @file
-  Driver implementing the Tiano Legacy 8259 Protocol
-
-Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _8259_H__
-#define _8259_H__
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-// 8259 Hardware definitions
-
-#define LEGACY_MODE_BASE_VECTOR_MASTER  0x08
-#define LEGACY_MODE_BASE_VECTOR_SLAVE   0x70
-
-#define PROTECTED_MODE_BASE_VECTOR_MASTER  0x68
-#define PROTECTED_MODE_BASE_VECTOR_SLAVE   0x70
-
-#define LEGACY_8259_CONTROL_REGISTER_MASTER   0x20
-#define LEGACY_8259_MASK_REGISTER_MASTER  0x21
-#define LEGACY_8259_CONTROL_REGISTER_SLAVE0xA0
-#define LEGACY_8259_MASK_REGIST

[edk2-devel] [PATCH 33/37] OvmfPkg: exclude 8259InterruptControllerDxe

[Laszlo Ersek]

With 8254TimerDxe gone, no module in OVMF consumes
gEfiLegacy8259ProtocolGuid; exclude 8259InterruptControllerDxe therefore.

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
 OvmfPkg/OvmfPkgX64.dsc | 3 ---
 OvmfPkg/OvmfPkgIa32.fdf| 3 ---
 OvmfPkg/OvmfPkgIa32X64.fdf | 3 ---
 OvmfPkg/OvmfPkgX64.fdf | 3 ---
 6 files changed, 18 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index a98406cb8ca6..8021c2f325f3 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -753,9 +753,6 @@ [Components]
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/8259InterruptControllerDxe/8259.inf
-!endif
   OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 6962735f668f..66025fae1fa2 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -767,9 +767,6 @@ [Components.X64]
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/8259InterruptControllerDxe/8259.inf
-!endif
   OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 7429136a1ffa..9b1168076f42 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -835,9 +835,6 @@ [Components]
   NULL|OvmfPkg/Library/MpInitLibDepLib/DxeMpInitLibUpDepLib.inf
   }
 
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/8259InterruptControllerDxe/8259.inf
-!endif
   OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index c1ff11f50e31..501b4de4695e 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -219,9 +219,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
-!ifdef $(CSM_ENABLE)
-  INF OvmfPkg/8259InterruptControllerDxe/8259.inf
-!endif
 INF  OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 11d73a16df7e..74cfb58f06cd 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -220,9 +220,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
-!ifdef $(CSM_ENABLE)
-  INF OvmfPkg/8259InterruptControllerDxe/8259.inf
-!endif
 INF  OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index dd97615b0d8d..f47ab1727e4c 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -245,9 +245,6 @@ [FV.DXEFV]
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
 INF  FILE_GUID = $(UP_CPU_DXE_GUID) UefiCpuPkg/CpuDxe/CpuDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  INF  OvmfPkg/8259InterruptControllerDxe/8259.inf
-!endif
 INF  OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf



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

[edk2-devel] [PATCH 32/37] OvmfPkg: remove 8254TimerDxe

[Laszlo Ersek]

8254TimerDxe is not used by any platforms at this point, remove it.

This patch removes mentions of the following CSM resources from the source
code:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid

- headers:
  - Protocol/Legacy8259.h

which extends the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid

- headers:
  - Protocol/Legacy8259.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/8254TimerDxe/Timer.uni  |  16 -
 OvmfPkg/8254TimerDxe/TimerExtra.uni |  14 -
 OvmfPkg/8254TimerDxe/8254Timer.inf  |  43 ---
 OvmfPkg/8254TimerDxe/Timer.h| 186 -
 OvmfPkg/8254TimerDxe/Timer.c| 406 
 5 files changed, 665 deletions(-)

diff --git a/OvmfPkg/8254TimerDxe/Timer.uni b/OvmfPkg/8254TimerDxe/Timer.uni
deleted file mode 100644
index 7f3d35f4e1cd..
--- a/OvmfPkg/8254TimerDxe/Timer.uni
+++ /dev/null
@@ -1,16 +0,0 @@
-// /** @file
-// 8254 timer driver that provides Timer Arch protocol.
-//
-// 8254 timer driver that provides Timer Arch protocol.
-//
-// Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-
-#string STR_MODULE_ABSTRACT #language en-US "8254 timer driver 
that provides Timer Arch protocol"
-
-#string STR_MODULE_DESCRIPTION  #language en-US "8254 timer driver 
that provides Timer Arch protocol."
-
diff --git a/OvmfPkg/8254TimerDxe/TimerExtra.uni 
b/OvmfPkg/8254TimerDxe/TimerExtra.uni
deleted file mode 100644
index 7a54767a451b..
--- a/OvmfPkg/8254TimerDxe/TimerExtra.uni
+++ /dev/null
@@ -1,14 +0,0 @@
-// /** @file
-// Timer Localized Strings and Content
-//
-// Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-#string STR_PROPERTIES_MODULE_NAME
-#language en-US
-"8254 Timer DXE Driver"
-
-
diff --git a/OvmfPkg/8254TimerDxe/8254Timer.inf 
b/OvmfPkg/8254TimerDxe/8254Timer.inf
deleted file mode 100644
index 8fbab896f01b..
--- a/OvmfPkg/8254TimerDxe/8254Timer.inf
+++ /dev/null
@@ -1,43 +0,0 @@
-## @file
-# 8254 timer driver that provides Timer Arch protocol.
-#
-# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
-# SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = Timer
-  MODULE_UNI_FILE= Timer.uni
-  FILE_GUID  = C190FE35-44AA-41A1-8AEA-4947BC60E09D
-  MODULE_TYPE= DXE_DRIVER
-  VERSION_STRING = 1.0
-
-  ENTRY_POINT= TimerDriverInitialize
-
-[Packages]
-  MdePkg/MdePkg.dec
-  OvmfPkg/OvmfPkg.dec
-
-[LibraryClasses]
-  UefiBootServicesTableLib
-  BaseLib
-  DebugLib
-  NestedInterruptTplLib
-  UefiDriverEntryPoint
-  IoLib
-
-[Sources]
-  Timer.h
-  Timer.c
-
-[Protocols]
-  gEfiCpuArchProtocolGuid   ## CONSUMES
-  gEfiLegacy8259ProtocolGuid## CONSUMES
-  gEfiTimerArchProtocolGuid ## PRODUCES
-
-[Depex]
-  gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
-[UserExtensions.TianoCore."ExtraFiles"]
-  TimerExtra.uni
diff --git a/OvmfPkg/8254TimerDxe/Timer.h b/OvmfPkg/8254TimerDxe/Timer.h
deleted file mode 100644
index b19ef3c1f94e..
--- a/OvmfPkg/8254TimerDxe/Timer.h
+++ /dev/null
@@ -1,186 +0,0 @@
-/** @file
-  Private data structures
-
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-**/
-
-#ifndef _TIMER_H_
-#define _TIMER_H_
-
-#include 
-
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-//
-// The PCAT 8253/8254 has an input clock at 1.193182 MHz and Timer 0 is
-// initialized as a 16 bit free running counter that generates an 
interrupt(IRQ0)
-// each time the counter rolls over.
-//
-//   65536 counts
-//  * 1,000,000 uS/S = 54925.4 uS = 549254 * 100 ns
-//   1,193,182 Hz
-//
-
-//
-// The maximum tick duration for 8254 timer
-//
-#define MAX_TIMER_TICK_DURATION  549254
-//
-// The default timer tick duration is set to 10 ms = 10 100 ns units
-//
-#define DEFAULT_TIMER_TICK_DURATION  10
-#define TIMER_CONTROL_PORT   0x43
-#define TIMER0_COUNT_PORT0x40
-
-//
-// Function Prototypes
-//
-
-/**
-  Initialize the Timer Architectural Protocol driver
-
-  @param ImageHandle ImageHandle of the loaded driver
-  @param SystemTable Pointer to the System Table
-
-  @retval EFI_SUCCESSTimer Architectural Protocol created
-  @retval EFI_OUT_OF_RESOURCES   Not enough resources available to initialize 
driver.
-  @retval EFI_DEVICE_ERROR   A device error occurred attempting to 
initialize the driver.
-
-**/
-EFI_STATUS
-EFIAPI
-

[edk2-devel] [PATCH 30/37] OvmfPkg: remove Csm16

[Laszlo Ersek]

Csm16 is not used by any platform at this point, remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid

- headers:
  - Protocol/Legacy8259.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Csm/Csm16/Csm16.inf  | 17 -
 OvmfPkg/Csm/Csm16/ReadMe.txt | 12 
 2 files changed, 29 deletions(-)

diff --git a/OvmfPkg/Csm/Csm16/Csm16.inf b/OvmfPkg/Csm/Csm16/Csm16.inf
deleted file mode 100644
index 2bd33e309d7b..
--- a/OvmfPkg/Csm/Csm16/Csm16.inf
+++ /dev/null
@@ -1,17 +0,0 @@
-## @file
-#  CSM Binary
-#
-#  Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = Csm16
-  FILE_GUID  = 1547B4F3-3E8A-4FEF-81C8-328ED647AB1A
-  MODULE_TYPE= USER_DEFINED
-  VERSION_STRING = 1.0
-
-[Binaries]
-  BIN|Csm16.bin|*
\ No newline at end of file
diff --git a/OvmfPkg/Csm/Csm16/ReadMe.txt b/OvmfPkg/Csm/Csm16/ReadMe.txt
deleted file mode 100644
index 4d5d086bb4a2..
--- a/OvmfPkg/Csm/Csm16/ReadMe.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-This module allows a CSM16 binary to be easily included
-in the OVMF.fd output file.
-
-=== How to use Csm16.inf ===
-
-1. Copy the CSM16 binary to OvmfPkg/Csm/Csm16/Csm16.bin
-2. Build OVMF with CSM_ENABLE defined.
-
-   For example:
-   * build -D CSM_ENABLE, or
-   * OvmfPkg/build.sh -D CSM_ENABLE
-



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

[edk2-devel] [PATCH 29/37] OvmfPkg: remove Rule.Common.USER_DEFINED.CSM from all FDF files

[Laszlo Ersek]

We no longer have

  INF  RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf

lines in any of the OVMF platform FDF files; remove the CSM rules
themselves.

(Note that some of the more recent platforms had cargo-culted this rule
from the original ones, without ever referencing the rule with
RuleOverride=CSM. Remove those rules as well.)

Cc: Anatol Belski 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jianyong Wu 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.fdf   | 5 -
 OvmfPkg/CloudHv/CloudHvX64.fdf   | 5 -
 OvmfPkg/IntelTdx/IntelTdxX64.fdf | 5 -
 OvmfPkg/Microvm/MicrovmX64.fdf   | 5 -
 OvmfPkg/OvmfPkgIa32.fdf  | 5 -
 OvmfPkg/OvmfPkgIa32X64.fdf   | 5 -
 OvmfPkg/OvmfPkgX64.fdf   | 5 -
 OvmfPkg/OvmfXen.fdf  | 5 -
 8 files changed, 40 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf
index 9cd059de159f..497c6753ce9b 100644
--- a/OvmfPkg/Bhyve/BhyveX64.fdf
+++ b/OvmfPkg/Bhyve/BhyveX64.fdf
@@ -454,11 +454,6 @@ [Rule.Common.USER_DEFINED.ACPITABLE]
 RAW ASL|.aml
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index eac6557e6b74..eae3ada1913c 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -458,11 +458,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
index 69074cfb1e73..e844a0988d68 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
@@ -431,11 +431,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/Microvm/MicrovmX64.fdf b/OvmfPkg/Microvm/MicrovmX64.fdf
index a9b6618ca811..c877b3f088f9 100644
--- a/OvmfPkg/Microvm/MicrovmX64.fdf
+++ b/OvmfPkg/Microvm/MicrovmX64.fdf
@@ -416,11 +416,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index f7652bb7009c..44e3b4e140d0 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -484,11 +484,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 74049ec129d2..1fbfdd40c58a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -487,11 +487,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 48b97d90e820..2220d1769c91 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -521,11 +521,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM]
-  FILE FREEFORM = $(NAMED_GUID) {
-RAW BIN|.bin
-  }
-
 [Rule.Common.SEC.RESET_VECTOR]
   FILE RAW = $(NAMED_GUID) {
 RAW BIN   Align = 16   |.bin
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 18f8c81b0ef7..5770b173168b 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -462,11 +462,6 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
 VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
-[Rule.Common.USER_DEFINED.CSM

[edk2-devel] [PATCH 28/37] OvmfPkg: exclude Csm16.inf / Csm16.bin

[Laszlo Ersek]

The Csm16 module wraps the CONFIG_CSM build of SeaBIOS. "Csm16.inf" has
FILE_GUID 1547B4F3-3E8A-4FEF-81C8-328ED647AB1A, which was previously
referenced by the (now removed) CsmSupportLib, under the name
SYSTEM_ROM_FILE_GUID.

Nothing relies on the SeaBIOS binary any longer, so exclude the Csm16
module from all OVMF platforms.

(Note that the "OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf" pathname that
the BhyveX64 platform refers to is bogus anyway.)

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc | 4 
 OvmfPkg/OvmfPkgIa32.dsc| 4 
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 
 OvmfPkg/OvmfPkgX64.dsc | 4 
 OvmfPkg/OvmfXen.dsc| 4 
 OvmfPkg/Bhyve/BhyveX64.fdf | 4 
 OvmfPkg/OvmfPkgIa32.fdf| 4 
 OvmfPkg/OvmfPkgIa32X64.fdf | 4 
 OvmfPkg/OvmfPkgX64.fdf | 4 
 OvmfPkg/OvmfXen.fdf| 4 
 10 files changed, 40 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index b26e5053f69b..85ad6b194c91 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -762,10 +762,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf
-!endif
-
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d4f4460425c3..fcd7f4a58957 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -886,10 +886,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/Csm16/Csm16.inf
-!endif
-
 !if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 6e87a7a43704..8cbe3733aba2 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -900,10 +900,6 @@ [Components.X64]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/Csm16/Csm16.inf
-!endif
-
 !if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 1916abdf67f1..288c2cf28abf 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -968,10 +968,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/Csm16/Csm16.inf
-!endif
-
 !if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 4e195b66c379..d8552ad37ea2 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -693,10 +693,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/Csm16/Csm16.inf
-!endif
-
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf
index 8b5aa46a1e33..9cd059de159f 100644
--- a/OvmfPkg/Bhyve/BhyveX64.fdf
+++ b/OvmfPkg/Bhyve/BhyveX64.fdf
@@ -295,10 +295,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-INF  RuleOverride=CSM OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf
-!endif
-
 INF  OvmfPkg/PlatformDxe/Platform.inf
 INF  OvmfPkg/AmdSevDxe/AmdSevDxe.inf
 INF  OvmfPkg/IoMmuDxe/IoMmuDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index d55a6e1590d0..f7652bb7009c 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -325,10 +325,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-INF  RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
-!endif
-
 INF  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 INF  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
 INF  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index d9ae001a669d..74049ec129d2 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -331,10 +331,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 

[edk2-devel] [PATCH 31/37] OvmfPkg: exclude 8254TimerDxe

[Laszlo Ersek]

In the original three OVMF platforms, CSM_ENABLE selects the legacy timer
driver; exclude it. Instead, include LocalApicTimerDxe unconditionally
(which in turn consumes PcdFSBClock).

Background: commits c37cbc030d96 ("OvmfPkg: Switch timer in build time for
OvmfPkg", 2022-04-02) and 07c0c2eb0a59 ("OvmfPkg: fix PcdFSBClock",
2022-05-25).

Regression test: verified that the BDS progress bar still advanced at
normal speed in each platform.

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 6 +-
 OvmfPkg/OvmfPkgIa32X64.dsc | 6 +-
 OvmfPkg/OvmfPkgX64.dsc | 6 +-
 OvmfPkg/OvmfPkgIa32.fdf| 4 +---
 OvmfPkg/OvmfPkgIa32X64.fdf | 4 +---
 OvmfPkg/OvmfPkgX64.fdf | 4 +---
 6 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index fcd7f4a58957..a98406cb8ca6 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -669,9 +669,7 @@ [PcdsDynamicDefault]
   # Set ConfidentialComputing defaults
   gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0
 
-!if $(CSM_ENABLE) == FALSE
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock|10
-!endif
 
 [PcdsDynamicHii]
 !include OvmfPkg/Include/Dsc/OvmfTpmPcdsHii.dsc.inc
@@ -757,10 +755,8 @@ [Components]
   UefiCpuPkg/CpuDxe/CpuDxe.inf
 !ifdef $(CSM_ENABLE)
   OvmfPkg/8259InterruptControllerDxe/8259.inf
-  OvmfPkg/8254TimerDxe/8254Timer.inf
-!else
+!endif
   OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
-!endif
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 8cbe3733aba2..6962735f668f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -677,9 +677,7 @@ [PcdsDynamicDefault]
   # Set ConfidentialComputing defaults
   gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0
 
-!if $(CSM_ENABLE) == FALSE
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock|10
-!endif
 
 [PcdsDynamicDefault.X64]
   # IPv4 and IPv6 PXE Boot support.
@@ -771,10 +769,8 @@ [Components.X64]
   UefiCpuPkg/CpuDxe/CpuDxe.inf
 !ifdef $(CSM_ENABLE)
   OvmfPkg/8259InterruptControllerDxe/8259.inf
-  OvmfPkg/8254TimerDxe/8254Timer.inf
-!else
+!endif
   OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
-!endif
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 288c2cf28abf..7429136a1ffa 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -701,9 +701,7 @@ [PcdsDynamicDefault]
   # Set ConfidentialComputing defaults
   gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0
 
-!if $(CSM_ENABLE) == FALSE
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock|10
-!endif
 
 [PcdsDynamicHii]
 !include OvmfPkg/Include/Dsc/OvmfTpmPcdsHii.dsc.inc
@@ -839,10 +837,8 @@ [Components]
 
 !ifdef $(CSM_ENABLE)
   OvmfPkg/8259InterruptControllerDxe/8259.inf
-  OvmfPkg/8254TimerDxe/8254Timer.inf
-!else
+!endif
   OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
-!endif
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 44e3b4e140d0..c1ff11f50e31 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -221,10 +221,8 @@ [FV.DXEFV]
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
 !ifdef $(CSM_ENABLE)
   INF OvmfPkg/8259InterruptControllerDxe/8259.inf
-  INF OvmfPkg/8254TimerDxe/8254Timer.inf
-!else
-  INF OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 !endif
+INF  OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
 INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 1fbfdd40c58a..11d73a16df7e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -222,10 +222,8 @@ [FV.DXEFV]
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
 !ifdef $(CSM_ENABLE)
   INF OvmfPkg/8259InterruptControllerDxe/8259.inf
-  INF OvmfPkg/8254TimerDxe/8254Timer.inf
-!else
-  INF OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 !endif
+INF  OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
 INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 2220d1769c91.

[edk2-devel] [PATCH 27/37] OvmfPkg: remove

[Laszlo Ersek]

The  header is not used by any source file at this point,
remove it.

 is a thin wrapper for including all header files under
the "OvmfPkg/Csm/Include/Framework" directory. Remove that directory at
the same time (nothing else references contents in that directory
directly).

Consequently, the "OvmfPkg/Csm/Include" directory becomes empty, and git
automatically deletes it; remove that include path from
"OvmfPkg/OvmfPkg.dec".

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiLegacy8259ProtocolGuid

- headers:
  - Protocol/Legacy8259.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec |   1 -
 OvmfPkg/Csm/Include/Framework/BootScript.h  |  40 --
 OvmfPkg/Csm/Include/Framework/DxeCis.h  | 169 
-
 OvmfPkg/Csm/Include/Framework/FirmwareVolumeHeader.h|  79 
 OvmfPkg/Csm/Include/Framework/FirmwareVolumeImageFormat.h   |  32 --
 OvmfPkg/Csm/Include/Framework/FrameworkInternalFormRepresentation.h | 396 

 OvmfPkg/Csm/Include/Framework/Hob.h |  28 --
 OvmfPkg/Csm/Include/Framework/StatusCode.h  | 155 

 OvmfPkg/Csm/Include/FrameworkDxe.h  |  26 --
 9 files changed, 926 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 32543e466ad7..9d326e8143eb 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -17,7 +17,6 @@ [Defines]
 
 [Includes]
   Include
-  Csm/Include
 
 [LibraryClasses]
   ##  @libraryclass  Search and install ACPI tables.
diff --git a/OvmfPkg/Csm/Include/Framework/BootScript.h 
b/OvmfPkg/Csm/Include/Framework/BootScript.h
deleted file mode 100644
index ea1d03cf479d..
--- a/OvmfPkg/Csm/Include/Framework/BootScript.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/** @file
-  This file contains the boot script definitions that are shared between the
-  Boot Script Executor PPI and the Boot Script Save Protocol.
-
-Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _BOOT_SCRIPT_H_
-#define _BOOT_SCRIPT_H_
-
-#include 
-///
-/// The framework implementation defines follow opcode that are different from 
the PI specification:
-/// Add FRAMEWORK_ prefix to avoid naming conflict.
-///
-/// S3 Boot Script Table identifier.
-///
-#define FRAMEWORK_EFI_ACPI_S3_RESUME_SCRIPT_TABLE  0x00
-///
-/// The opcode is used to add a record for memory reads of the memory location 
and continues when the
-/// exit criteria is satisfied, or after a defined duration.
-///
-#define FRAMEWORK_EFI_BOOT_SCRIPT_MEM_POLL_OPCODE  0x09
-///
-/// The opcode is used to add a record for dispatching specified arbitrary 
code into a specified
-/// boot script table.
-///
-#define FRAMEWORK_EFI_BOOT_SCRIPT_DISPATCH_2_OPCODE  0x0D
-///
-/// The opcode indicates the start of the boot script table.
-///
-#define FRAMEWORK_EFI_BOOT_SCRIPT_TABLE_OPCODE  0xAA
-///
-/// The opcode indicates the end of the boot script table.
-///
-#define FRAMEWORK_EFI_BOOT_SCRIPT_TERMINATE_OPCODE  0xFF
-
-#endif
diff --git a/OvmfPkg/Csm/Include/Framework/DxeCis.h 
b/OvmfPkg/Csm/Include/Framework/DxeCis.h
deleted file mode 100644
index d2ee61d681fb..
--- a/OvmfPkg/Csm/Include/Framework/DxeCis.h
+++ /dev/null
@@ -1,169 +0,0 @@
-/** @file
-  Include file for definitions in the Intel Platform Innovation Framework for 
EFI
-  Driver Execution Environment Core Interface Specification (DXE CIS) Version 
0.91.
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _DXECIS_H_
-#define _DXECIS_H_
-
-#include 
-
-/**
-  Functions of this type are used with the Framework MP Services Protocol and
-  the  SMM Services Table to execute a procedure on enabled APs.  The context
-  the AP should use durng execution is specified by Buffer.
-
-  @param[in]  Buffer   The pointer to the procedure's argument.
-
-**/
-typedef
-VOID
-(EFIAPI *FRAMEWORK_EFI_AP_PROCEDURE)(
-  IN  VOID  *Buffer
-  );
-
-///
-/// The Framework EFI Runtime Services Table as an extension to the EFI 1.10 
Runtime Services Table.
-///
-typedef struct {
-  //
-  // Table header for the Framework EFI Runtime Services Table
-  //
-  EFI_TABLE_HEADERHdr;
-  //
-  // Time services
-  //
-  EFI_GET_TIMEGetTime;
-  EFI_SET_TIMESetTime;
-  EFI_GET_WAKEUP_TIME GetWakeupTime;
-  EFI_SET_WAKEUP_TIME SetWakeupTime;
-  //
-  // Virtual memory services
-  //
-  EFI_SET_VIRTUAL_ADDRESS_MAP SetVirtualAddressMap;
-  EFI_CONVERT_POIN

[edk2-devel] [PATCH 26/37] OvmfPkg: remove gEfiLegacyInterruptProtocolGuid

[Laszlo Ersek]

At this point, gEfiLegacyInterruptProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiLegacy8259ProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/Legacy8259.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec|   1 -
 OvmfPkg/Csm/Include/Protocol/LegacyInterrupt.h | 121 
 2 files changed, 122 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 9c2e84ca6060..32543e466ad7 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -183,7 +183,6 @@ [Protocols]
   gXenIoProtocolGuid= {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
   gIoMmuAbsentProtocolGuid  = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
   gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
-  gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
   gOvmfLoadedX86LinuxKernelProtocolGuid = {0xa3edc05d, 0xb618, 0x4ff6, {0x95, 
0x52, 0x76, 0xd7, 0x88, 0x63, 0x43, 0xc8}}
   gOvmfSevMemoryAcceptanceProtocolGuid  = {0xc5a010fe, 0x38a7, 0x4531, {0x8a, 
0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49}}
   gQemuAcpiTableNotifyProtocolGuid  = {0x928939b2, 0x4235, 0x462f, {0x95, 
0x80, 0xf6, 0xa2, 0xb2, 0xc2, 0x1a, 0x4f}}
diff --git a/OvmfPkg/Csm/Include/Protocol/LegacyInterrupt.h 
b/OvmfPkg/Csm/Include/Protocol/LegacyInterrupt.h
deleted file mode 100644
index 8287ad5b5c1c..
--- a/OvmfPkg/Csm/Include/Protocol/LegacyInterrupt.h
+++ /dev/null
@@ -1,121 +0,0 @@
-/** @file
-  This protocol abstracts the PIRQ programming from the generic EFI 
Compatibility Support Modules (CSMs).
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  This protocol is defined in Framework for the EFI Compatibility Support 
Module specification.
-  Version 0.97.
-
-**/
-
-#ifndef _EFI_LEGACY_INTERRUPT_H_
-#define _EFI_LEGACY_INTERRUPT_H_
-
-#define EFI_LEGACY_INTERRUPT_PROTOCOL_GUID \
-  { \
-0x31ce593d, 0x108a, 0x485d, {0xad, 0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 
0xbe } \
-  }
-
-typedef struct _EFI_LEGACY_INTERRUPT_PROTOCOL EFI_LEGACY_INTERRUPT_PROTOCOL;
-
-/**
-  Get the number of PIRQs this hardware supports.
-
-  @param  This  The protocol instance pointer.
-  @param  NumberPirsq   The number of PIRQs that are supported.
-
-  @retval EFI_SUCCESS   The number of PIRQs was returned successfully.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_LEGACY_INTERRUPT_GET_NUMBER_PIRQS)(
-  IN EFI_LEGACY_INTERRUPT_PROTOCOL*This,
-  OUT UINT8   *NumberPirqs
-  );
-
-/**
-  Gets the PCI location associated with this protocol.
-
-  @param  This  The Protocol instance pointer.
-  @param  Bus   The PCI Bus.
-  @param  DeviceThe PCI Device.
-  @param  Function  The PCI Function.
-
-  @retval EFI_SUCCESS   The Bus, Device, and Function were returned 
successfully.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_LEGACY_INTERRUPT_GET_LOCATION)(
-  IN EFI_LEGACY_INTERRUPT_PROTOCOL*This,
-  OUT UINT8   *Bus,
-  OUT UINT8   *Device,
-  OUT UINT8   *Function
-  );
-
-/**
-  Read the PIRQ register and return the data
-
-  @param  This  The protocol instance pointer.
-  @param  PirqNumberThe PIRQ register to read.
-  @param  PirqData  The data read.
-
-  @retval EFI_SUCCESS   The data was read.
-  @retval EFI_INVALID_PARAMETER Invalid PIRQ number.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_LEGACY_INTERRUPT_READ_PIRQ)(
-  IN EFI_LEGACY_INTERRUPT_PROTOCOL   *This,
-  IN  UINT8  PirqNumber,
-  OUT UINT8  *PirqData
-  );
-
-/**
-  Write the specified PIRQ register with the given data.
-
-  @param  This  The protocol instance pointer.
-  @param  PirqNumberA PIRQ register to read.
-  @param  PirqData  The data to write.
-
-  @retval EFI_SUCCESS   The PIRQ was programmed.
-  @retval EFI_INVALID_PARAMETER Invalid PIRQ number.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_LEGACY_INTERRUPT_WRITE_PIRQ)(
-  IN EFI_LEGACY_INTERRUPT_PROTOCOL   *This,
-  IN  UINT8  PirqNumber,
-  IN UINT8   PirqData
-  );
-
-struct _EFI_LEGACY_INTERRUPT_PROTOCOL {
-  ///
-  ///   Gets

[edk2-devel] [PATCH 25/37] OvmfPkg: remove gEfiLegacyBiosProtocolGuid

[Laszlo Ersek]

At this point, gEfiLegacyBiosProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyInterrupt.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec   |1 -
 OvmfPkg/Csm/Include/Protocol/LegacyBios.h | 1551 
 2 files changed, 1552 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index d257007c236a..9c2e84ca6060 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -183,7 +183,6 @@ [Protocols]
   gXenIoProtocolGuid= {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
   gIoMmuAbsentProtocolGuid  = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
   gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
-  gEfiLegacyBiosProtocolGuid= {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
   gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
   gOvmfLoadedX86LinuxKernelProtocolGuid = {0xa3edc05d, 0xb618, 0x4ff6, {0x95, 
0x52, 0x76, 0xd7, 0x88, 0x63, 0x43, 0xc8}}
   gOvmfSevMemoryAcceptanceProtocolGuid  = {0xc5a010fe, 0x38a7, 0x4531, {0x8a, 
0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49}}
diff --git a/OvmfPkg/Csm/Include/Protocol/LegacyBios.h 
b/OvmfPkg/Csm/Include/Protocol/LegacyBios.h
deleted file mode 100644
index b9a225a8748e..
--- a/OvmfPkg/Csm/Include/Protocol/LegacyBios.h
+++ /dev/null
@@ -1,1551 +0,0 @@
-/** @file
-  The EFI Legacy BIOS Protocol is used to abstract legacy Option ROM usage
-  under EFI and Legacy OS boot.  This file also includes all the related
-  COMPATIBILITY16 structures and definitions.
-
-  Note: The names for EFI_IA32_REGISTER_SET elements were picked to follow
-  well known naming conventions.
-
-  Thunk is the code that switches from 32-bit protected environment into the 
16-bit real-mode
-  environment. Reverse thunk is the code that does the opposite.
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  This protocol is defined in Framework for EFI Compatibility Support Module 
spec
-  Version 0.98.
-
-**/
-
-#ifndef _EFI_LEGACY_BIOS_H_
-#define _EFI_LEGACY_BIOS_H_
-
-///
-///
-///
-#pragma pack(1)
-
-typedef UINT8  SERIAL_MODE;
-typedef UINT8  PARALLEL_MODE;
-
-#define EFI_COMPATIBILITY16_TABLE_SIGNATURE  SIGNATURE_32 ('I', 'F', 'E', '$')
-
-///
-/// There is a table located within the traditional BIOS in either the 
0xF000: or 0xE000:
-/// physical address range. It is located on a 16-byte boundary and provides 
the physical address of the
-/// entry point for the Compatibility16 functions. These functions provide the 
platform-specific
-/// information that is required by the generic EfiCompatibility code. The 
functions are invoked via
-/// thunking by using EFI_LEGACY_BIOS_PROTOCOL.FarCall86() with the 32-bit 
physical
-/// entry point.
-///
-typedef struct {
-  ///
-  /// The string "$EFI" denotes the start of the EfiCompatibility table. Byte 
0 is "I," byte
-  /// 1 is "F," byte 2 is "E," and byte 3 is "$" and is normally accessed as a 
DWORD or UINT32.
-  ///
-  UINT32Signature;
-
-  ///
-  /// The value required such that byte checksum of TableLength equals zero.
-  ///
-  UINT8 TableChecksum;
-
-  ///
-  /// The length of this table.
-  ///
-  UINT8 TableLength;
-
-  ///
-  /// The major EFI revision for which this table was generated.
-  ///
-  UINT8 EfiMajorRevision;
-
-  ///
-  /// The minor EFI revision for which this table was generated.
-  ///
-  UINT8 EfiMinorRevision;
-
-  ///
-  /// The major revision of this table.
-  ///
-  UINT8 TableMajorRevision;
-
-  ///
-  /// The minor revision of this table.
-  ///
-  UINT8 TableMinorRevision;
-
-  ///
-  /// Reserved for future usage.
-  ///
-  UINT16Reserved;
-
-  ///
-  /// The segment of the entry point within the traditional BIOS for 
Compatibility16 functions.
-  ///
-  UINT16Compatibility16CallSegment;
-
-  ///
-  /// The offset of the entry point within the traditional BIOS for 
Compatibility16 functions.
-  ///
-  UINT16Compatibility16CallOffset;
-
-  ///
-  /// The segment of the entry point within the traditional BIOS for 
EfiCompatibility
-  /// to invoke the PnP installation check.
-  ///
-  UINT16PnPInstallationCheckSegment;
-
-  ///
-  /// The Offset of the entry point

[edk2-devel] [PATCH 22/37] OvmfPkg: remove CsmSupportLib

[Laszlo Ersek]

CsmSupportLib is not used by any platform at this point, remove it.

This patch removes mentions of the following CSM resources from the source
code [*]:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiFirmwareVolumeProtocolGuid (by cutting the
 link)
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/FirmwareVolume.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

which extends the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiFirmwareVolumeProtocolGuid
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/FirmwareVolume.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

[*] Note that gEfiLegacyRegion2ProtocolGuid, while a CSM-related protocol,
cannot be scheduled for removal, because the protocol GUID is defined in
"MdePkg.dec", and it's not only "OvmfPkg/Csm/CsmSupportLib" that produces
it in all of edk2, but also "MdeModulePkg/Universal/LegacyRegion2Dxe" (not
used by OVMF). For the same reason, the "Protocol/LegacyRegion2.h" header
(from MdePkg) cannot be scheduled for removal.

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf |   55 -
 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.h   |   48 -
 OvmfPkg/Csm/CsmSupportLib/LegacyInterrupt.h |  115 ---
 OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.h  |   97 --
 OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h|  202 
 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.c   |   31 -
 OvmfPkg/Csm/CsmSupportLib/LegacyInterrupt.c |  212 
 OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c  | 1086 
 OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c|  506 -
 9 files changed, 2352 deletions(-)

diff --git a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf 
b/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
deleted file mode 100644
index 45f201f07b5f..
--- a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
+++ /dev/null
@@ -1,55 +0,0 @@
-## @file
-#  Platform CSM Support Library
-#
-#  Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = CsmSupportLib
-  FILE_GUID  = 04e03541-4663-417d-93f6-976378247d61
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = CsmSupportLib
-
-  CONSTRUCTOR= CsmSupportLibConstructor
-
-#
-# The following information is for reference only and not required by the 
build tools.
-#
-#  VALID_ARCHITECTURES   = IA32 X64 EBC
-#
-
-[Sources]
-  CsmSupportLib.c
-  CsmSupportLib.h
-  LegacyInterrupt.c
-  LegacyInterrupt.h
-  LegacyPlatform.c
-  LegacyPlatform.h
-  LegacyRegion.c
-  LegacyRegion.h
-
-[Packages]
-  MdePkg/MdePkg.dec
-  OvmfPkg/OvmfPkg.dec
-
-[Pcd]
-  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
-
-[Protocols]
-  gEfiDevicePathProtocolGuid# PROTOCOL ALWAYS_CONSUMED
-  gEfiDiskInfoProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
-  gEfiLegacyBiosPlatformProtocolGuid# PROTOCOL ALWAYS_CONSUMED
-  gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
-  gEfiLegacyInterruptProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
-  gEfiLegacyRegion2ProtocolGuid # PROTOCOL ALWAYS_PRODUCED
-  gEfiPciIoProtocolGuid # PROTOCOL ALWAYS_CONSUMED
-
-[LibraryClasses]
-  BaseLib
-  PciLib
-  IoLib
-
diff --git a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.h 
b/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.h
deleted file mode 100644
index a6ee93f16739..
--- a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/** @file
-  Platform CSM Support Library
-
-  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
-
-  SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _CSM_SUPPORT_LIB_H_
-#define _CSM_SUPPORT_LIB_H_
-
-#include 
-
-/**
-  Initialize Legacy Region support
-
-  @retval EFI_SUCCESS   Successfully initialized
-
-**/
-EFI_STATUS
-LegacyRegionInit (
-  VOID
-  );
-
-/**
-  Initialize Legacy Interrupt support
-
-  @retval EFI_SUCCESS   Successfully initialized
-
-**/
-EFI_STATUS
-LegacyInterruptInstall (
-  VOID
-  );
-
-/**
-  Initialize Legacy Platform support
-
-  @retval EFI_SUCCESS   Successfully initialized
-
-**/
-EFI_STATUS
-LegacyBiosPlatformInstall (
-  VOID

[edk2-devel] [PATCH 24/37] OvmfPkg: remove gEfiLegacyBiosPlatformProtocolGuid

[Laszlo Ersek]

At this point, gEfiLegacyBiosPlatformProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyInterrupt.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec   |   1 -
 OvmfPkg/Csm/Include/Protocol/LegacyBiosPlatform.h | 753 
 2 files changed, 754 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 94ad22d9501b..d257007c236a 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -184,7 +184,6 @@ [Protocols]
   gIoMmuAbsentProtocolGuid  = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
   gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
   gEfiLegacyBiosProtocolGuid= {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
-  gEfiLegacyBiosPlatformProtocolGuid= {0x783658a3, 0x4172, 0x4421, {0xa2, 
0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
   gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
   gOvmfLoadedX86LinuxKernelProtocolGuid = {0xa3edc05d, 0xb618, 0x4ff6, {0x95, 
0x52, 0x76, 0xd7, 0x88, 0x63, 0x43, 0xc8}}
   gOvmfSevMemoryAcceptanceProtocolGuid  = {0xc5a010fe, 0x38a7, 0x4531, {0x8a, 
0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49}}
diff --git a/OvmfPkg/Csm/Include/Protocol/LegacyBiosPlatform.h 
b/OvmfPkg/Csm/Include/Protocol/LegacyBiosPlatform.h
deleted file mode 100644
index 941b1c833159..
--- a/OvmfPkg/Csm/Include/Protocol/LegacyBiosPlatform.h
+++ /dev/null
@@ -1,753 +0,0 @@
-/** @file
-  The EFI Legacy BIOS Platform Protocol is used to mate a Legacy16
-  implementation with this EFI code. The EFI driver that produces
-  the Legacy BIOS protocol is generic and consumes this protocol.
-  A driver that matches the Legacy16 produces this protocol
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  This protocol is defined in Framework for EFI Compatibility Support Module 
spec
-  Version 0.97.
-
-**/
-
-#ifndef _EFI_LEGACY_BIOS_PLATFORM_H_
-#define _EFI_LEGACY_BIOS_PLATFORM_H_
-
-///
-/// Legacy BIOS Platform depends on HDD_INFO and EFI_COMPATIBILITY16_TABLE that
-/// are defined with the Legacy BIOS Protocol
-///
-#include 
-
-#define EFI_LEGACY_BIOS_PLATFORM_PROTOCOL_GUID \
-  { \
-0x783658a3, 0x4172, 0x4421, {0xa2, 0x99, 0xe0, 0x9, 0x7, 0x9c, 0xc, 0xb4 } 
\
-  }
-
-typedef struct _EFI_LEGACY_BIOS_PLATFORM_PROTOCOL 
EFI_LEGACY_BIOS_PLATFORM_PROTOCOL;
-
-/**
-  This enum specifies the Mode param values for GetPlatformInfo()
-**/
-typedef enum {
-  ///
-  /// This mode is invoked twice. The first invocation has LegacySegment and
-  /// LegacyOffset set to 0. The mode returns the MP table address in EFI 
memory, along with its size.
-  /// The second invocation has LegacySegment and LegacyOffset set to the 
location
-  /// in the 0xF or 0xE block to which the MP table is to be copied. 
The second
-  /// invocation allows any MP table address fixes to occur in the EFI memory 
copy of the
-  /// MP table. The caller, not EfiGetPlatformBinaryMpTable, copies the 
modified MP
-  /// table to the allocated region in 0xF or 0xE block after the 
second invocation.
-  ///
-  /// The function parameters associated with this mode are:
-  ///
-  ///   Table Pointer to the MP table.
-  ///
-  ///   TableSize Size in bytes of the MP table.
-  ///
-  ///   Location Location to place table. 0x00. Either 0xE or 0xF 64 
KB blocks.
-  /// Bit 0 = 1 0xF 64 KB block.
-  /// Bit 1 = 1 0xE 64 KB block.
-  /// Multiple bits can be set.
-  ///
-  ///   Alignment Bit-mapped address alignment granularity.
-  /// The first nonzero bit from the right is the address granularity.
-  ///
-  //LegacySegment Segment in which EfiCompatibility code will place the MP 
table.
-  ///
-  ///   LegacyOffset Offset in which EfiCompatibility code will place the MP 
table.
-  ///
-  /// The return values associated with this mode are:
-  ///
-  ///   EFI_SUCCESS The MP table was returned.
-  ///
-  ///   EFI_UNSUPPORTED The MP table is not supported on this platform.
-  ///
-  EfiGetPlatformBinaryMpTable = 0,
-  ///
-  /// This mode returns a block of data. The content and usage is IBV or OEM 
defined.
-  /// OEMs or IBVs normally use this function for nonstandard Compatibility16 
runtime soft
-  /// INTs. It is the responsibility of this routine

[edk2-devel] [PATCH 23/37] OvmfPkg: remove gEfiFirmwareVolumeProtocolGuid

[Laszlo Ersek]

At this point, gEfiFirmwareVolumeProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec   |   1 -
 OvmfPkg/Csm/Include/Protocol/FirmwareVolume.h | 339 
 2 files changed, 340 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 45a6105d39d6..94ad22d9501b 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -183,7 +183,6 @@ [Protocols]
   gXenIoProtocolGuid= {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
   gIoMmuAbsentProtocolGuid  = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
   gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
-  gEfiFirmwareVolumeProtocolGuid= {0x389F751F, 0x1838, 0x4388, {0x83, 
0x90, 0xcd, 0x81, 0x54, 0xbd, 0x27, 0xf8}}
   gEfiLegacyBiosProtocolGuid= {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
   gEfiLegacyBiosPlatformProtocolGuid= {0x783658a3, 0x4172, 0x4421, {0xa2, 
0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
   gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
diff --git a/OvmfPkg/Csm/Include/Protocol/FirmwareVolume.h 
b/OvmfPkg/Csm/Include/Protocol/FirmwareVolume.h
deleted file mode 100644
index bac03c11c408..
--- a/OvmfPkg/Csm/Include/Protocol/FirmwareVolume.h
+++ /dev/null
@@ -1,339 +0,0 @@
-/** @file
-  This file declares the Firmware Volume Protocol.
-
-  The Firmware Volume Protocol provides file-level access to the firmware 
volume.
-  Each firmware volume driver must produce an instance of the Firmware Volume
-  Protocol if the firmware volume is to be visible to the system. The Firmware
-  Volume Protocol also provides mechanisms for determining and modifying some
-  attributes of the firmware volume.
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  This protocol is defined in Firmware Volume specification.
-  Version 0.9.
-
-**/
-
-#ifndef _FIRMWARE_VOLUME_H_
-#define _FIRMWARE_VOLUME_H_
-
-//
-// Firmware Volume Protocol GUID definition
-//
-#define EFI_FIRMWARE_VOLUME_PROTOCOL_GUID \
-  { \
-0x389F751F, 0x1838, 0x4388, {0x83, 0x90, 0xCD, 0x81, 0x54, 0xBD, 0x27, 
0xF8 } \
-  }
-
-#define FV_DEVICE_SIGNATURE  SIGNATURE_32 ('_', 'F', 'V', '_')
-
-typedef struct _EFI_FIRMWARE_VOLUME_PROTOCOL EFI_FIRMWARE_VOLUME_PROTOCOL;
-
-//
-// FRAMEWORK_EFI_FV_ATTRIBUTES bit definitions
-//
-typedef UINT64 FRAMEWORK_EFI_FV_ATTRIBUTES;
-
-//
-// 
-// FRAMEWORK_EFI_FV_ATTRIBUTES bit definitions
-// 
-//
-#define EFI_FV_READ_DISABLE_CAP  0x0001ULL
-#define EFI_FV_READ_ENABLE_CAP   0x0002ULL
-#define EFI_FV_READ_STATUS   0x0004ULL
-
-#define EFI_FV_WRITE_DISABLE_CAP  0x0008ULL
-#define EFI_FV_WRITE_ENABLE_CAP   0x0010ULL
-#define EFI_FV_WRITE_STATUS   0x0020ULL
-
-#define EFI_FV_LOCK_CAP   0x0040ULL
-#define EFI_FV_LOCK_STATUS0x0080ULL
-#define EFI_FV_WRITE_POLICY_RELIABLE  0x0100ULL
-
-#define EFI_FV_ALIGNMENT_CAP  0x8000ULL
-#define EFI_FV_ALIGNMENT_20x0001ULL
-#define EFI_FV_ALIGNMENT_40x0002ULL
-#define EFI_FV_ALIGNMENT_80x0004ULL
-#define EFI_FV_ALIGNMENT_16   0x0008ULL
-#define EFI_FV_ALIGNMENT_32   0x0010ULL
-#define EFI_FV_ALIGNMENT_64   0x0020ULL
-#define EFI_FV_ALIGNMENT_128  0x0040ULL
-#define EFI_FV_ALIGNMENT_256  0x0080ULL
-#define EFI_FV_ALIGNMENT_512  0x0100ULL
-#define EFI_FV_ALIGNMENT_1K   0x0200ULL
-#define EFI_FV_ALIGNMENT_2K   0x0400ULL
-#define EFI_FV_ALIGNMENT_4K   0x0800ULL
-#define EFI_FV_ALIGNMENT_8K   0x1000ULL
-#define EFI_FV_ALIGNMENT_16K  0x2000ULL
-#define EFI_FV_ALIGNMENT_32K  0x4000ULL
-#define EFI_FV_ALIGNMENT_64K  0x8000ULL
-
-//
-// Protocol API definitions
-//
-
-/**
-  Retrieves attributes, insures positive polarity

[edk2-devel] [PATCH 21/37] OvmfPkg: unplug CsmSupportLib from BdsDxe

[Laszlo Ersek]

CsmSupportLib is effectively a hack. It produces the following protocols:

- Legacy Bios Platform,
- Legacy Interrupt,
- Legacy Region2.

(Note that the "OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf" file contains
an error where it claims that "Legacy Bios Platform" is "consumed" -- it
is not; the lib instance produces that protocol).

At the same time, the library instance consumes
gEfiLegacyBiosProtocolGuid.

This *seemingly* creates a circular dependency with LegacyBiosDxe, because
that driver has the exact opposite protocol usage patterns. The solution
is that LegacyBiosDxe has a DEPEX on the protocols produced by
CsmSupportLib, while CsmSupportLib consumes the Legacy Bios Protocol from
LegacyBiosDxe only in the member functions of the protocols it produces.
Therefore, once BdsDxe is dispatched, and the CsmSupportLib constructor
exposes those three protocols, LegacyBiosDxe can also be started by the
DXE dispatcher, and then the protocols from CsmSupportLib become
functional.

But the main reason why CsmSupportLib is a hack is that it should be a
normal platform DXE driver (called e.g. "CsmSupportDxe"), and not a NULL
class library that's randomly hooked into BdsDxe.

Given that we have removed LegacyBiosDxe earlier (so there is no DEPEX we
need to satisfy now, conceptually), unhook CsmSupportLib from BdsDxe.

--*--

Note that in the BhyveX64 platform, the pathname
"OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf" is bogus, and has
always been, since commit 656419f922c0 ("Add BhyvePkg, to support the
bhyve hypervisor", 2020-07-31).

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc | 1 -
 OvmfPkg/OvmfPkgIa32.dsc| 3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
 OvmfPkg/OvmfPkgX64.dsc | 3 ---
 OvmfPkg/OvmfXen.dsc| 7 +--
 5 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index a3452efc5a84..b26e5053f69b 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -666,7 +666,6 @@ [Components]
 
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
-  NULL|OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf
 !endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index eb6022bafed3..d4f4460425c3 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -780,9 +780,6 @@ [Components]
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-!endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5f63596eeb2c..6e87a7a43704 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -794,9 +794,6 @@ [Components.X64]
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-!endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4dcda2ab17c2..1916abdf67f1 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -862,9 +862,6 @@ [Components]
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-!endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index ddcc1d7ad48c..4e195b66c379 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -592,12 +592,7 @@ [Components]
   MdeModulePkg/Universal/Metronome/Metronome.inf
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
-  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
-
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-!endif
-  }
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   MdeModulePkg/Logo/LogoDxe.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {
 



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

[edk2-devel] [PATCH 19/37] OvmfPkg: remove gEfiLegacyBiosGuid

[Laszlo Ersek]

At this point, gEfiLegacyBiosGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

- PCDs:
  - PcdEbdaReservedMemorySize
  - PcdEndOpromShadowAddress
  - PcdHighPmmMemorySize
  - PcdLegacyBiosCacheLegacyRegion
  - PcdLowPmmMemorySize
  - PcdOpromReservedMemoryBase
  - PcdOpromReservedMemorySize

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec   |  1 -
 OvmfPkg/Csm/Include/Guid/LegacyBios.h | 29 
 2 files changed, 30 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index de4b6fe5c02b..060198e6278d 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -155,7 +155,6 @@ [Guids]
   gXenBusRootDeviceGuid = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
   gRootBridgesConnectedEventGroupGuid   = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
   gMicrosoftVendorGuid  = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 
0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
-  gEfiLegacyBiosGuid= {0x2E3044AC, 0x879F, 0x490F, {0x97, 
0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
   gQemuKernelLoaderFsMediaGuid  = {0x1428f772, 0xb64a, 0x441e, {0xb8, 
0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
   gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 
0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
   gConfidentialComputingSecretGuid  = {0xadf956ad, 0xe98c, 0x484c, {0xae, 
0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
diff --git a/OvmfPkg/Csm/Include/Guid/LegacyBios.h 
b/OvmfPkg/Csm/Include/Guid/LegacyBios.h
deleted file mode 100644
index b196844d00fc..
--- a/OvmfPkg/Csm/Include/Guid/LegacyBios.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/** @file
-  Defines a Tag GUID used to mark a UEFI legacy BIOS thunk driver based
-  on legacy BIOS services and legacy option ROM. This Tag GUID must be 
installed on
-  the ImageHandle of any module that follows the EFI Driver Model and uses
-  the Int86() or FarCall() services of the Legacy Bios Protocol to produce
-  a standard UEFI I/O Protocol.
-
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _LEGACY_BIOS_H_
-#define _LEGACY_BIOS_H_
-
-///
-/// The Global ID for the Legacy BIOS GUID that must be installed onto the 
ImageHandle
-/// of any module follows the EFI Driver Model and uses the Int86() or 
FarCall()
-/// services of the Legacy BIOS Protocol to produce a standard UEFI I/O 
Protocol.
-///
-#define EFI_LEGACY_BIOS_GUID \
-  { \
-0x2e3044ac, 0x879f, 0x490f, {0x97, 0x60, 0xbb, 0xdf, 0xaf, 0x69, 0x5f, 
0x50 } \
-  }
-
-extern EFI_GUID  gEfiLegacyBiosGuid;
-
-#endif



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

[edk2-devel] [PATCH 16/37] OvmfPkg: exclude NullMemoryTestDxe driver

[Laszlo Ersek]

NullMemoryTestDxe was included in the OVMF platforms in historical commit
999a815e9ff3 ("OvmfPkg: Add NullMemoryTestDxe driver", 2011-01-21). It
produces gEfiGenericMemTestProtocolGuid. With LegacyBiosDxe gone, the only
consumer of this protocol in all of edk2 is
"EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c". Thus, exclude
NullMemoryTestDxe from all OVMF platforms.

(Notably, ArmVirtPkg platforms don't include NullMemoryTestDxe either.)

Cc: Anatol Belski 
Cc: Andrei Warkentin 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: Jianyong Wu 
Cc: Jiewen Yao 
Cc: Michael Roth 
Cc: Min Xu 
Cc: Rebecca Cran 
Cc: Sunil V L 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc| 1 -
 OvmfPkg/Bhyve/BhyveX64.dsc  | 1 -
 OvmfPkg/CloudHv/CloudHvX64.dsc  | 1 -
 OvmfPkg/IntelTdx/IntelTdxX64.dsc| 1 -
 OvmfPkg/Microvm/MicrovmX64.dsc  | 1 -
 OvmfPkg/OvmfPkgIa32.dsc | 1 -
 OvmfPkg/OvmfPkgIa32X64.dsc  | 1 -
 OvmfPkg/OvmfPkgX64.dsc  | 1 -
 OvmfPkg/OvmfXen.dsc | 1 -
 OvmfPkg/AmdSev/AmdSevX64.fdf| 1 -
 OvmfPkg/Bhyve/BhyveX64.fdf  | 1 -
 OvmfPkg/CloudHv/CloudHvX64.fdf  | 1 -
 OvmfPkg/IntelTdx/IntelTdxX64.fdf| 1 -
 OvmfPkg/Microvm/MicrovmX64.fdf  | 1 -
 OvmfPkg/OvmfPkgIa32.fdf | 1 -
 OvmfPkg/OvmfPkgIa32X64.fdf  | 1 -
 OvmfPkg/OvmfPkgX64.fdf  | 1 -
 OvmfPkg/OvmfXen.fdf | 1 -
 OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf | 2 --
 19 files changed, 20 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 302c90e7c2b4..a00f4c12904c 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -691,7 +691,6 @@ [Components]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index c938ed76ee92..a3452efc5a84 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -711,7 +711,6 @@ [Components]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
   OvmfPkg/Bhyve/BhyveRfbDxe/BhyveRfbDxe.inf {
 
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index c23c7eaf6cc2..f6e4b2c628a3 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -795,7 +795,6 @@ [Components]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
   #
   # Serial Support
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 0177c174c2ab..af0ecb0453ea 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -682,7 +682,6 @@ [Components]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index ea1fa3e2963f..75c53c0bb287 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -787,7 +787,6 @@ [Components]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 3005ef771bea..eb6022bafed3 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -841,7 +841,6 @@ [Components]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
diff --git a/OvmfPkg/OvmfPkgI

[edk2-devel] [PATCH 20/37] OvmfPkg: remove LegacyBiosDxe PCDs

[Laszlo Ersek]

The following PCDs are unused at this point; remove them:

- PcdEbdaReservedMemorySize
- PcdEndOpromShadowAddress
- PcdHighPmmMemorySize
- PcdLegacyBiosCacheLegacyRegion
- PcdLowPmmMemorySize
- PcdOpromReservedMemoryBase
- PcdOpromReservedMemorySize

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec | 38 
 1 file changed, 38 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 060198e6278d..45a6105d39d6 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -288,44 +288,6 @@ [PcdsFixedAtBuild]
   #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
   gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x5
 
-  ## Indicates if memory space for legacy region will be set as cacheable.
-  #   TRUE  - Set cachebility for legacy region.
-  #   FALSE - Does not set cachebility for legacy region.
-  gUefiOvmfPkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion|TRUE|BOOLEAN|0x2b
-
-  ## Specify memory size with bytes to reserve EBDA below 640K for OPROM.
-  #  The value should be a multiple of 4KB.
-  gUefiOvmfPkgTokenSpaceGuid.PcdEbdaReservedMemorySize|0x8000|UINT32|0x2c
-
-  ## Specify memory base address for OPROM to find free memory.
-  #  Some OPROMs do not use EBDA or PMM to allocate memory for its usage,
-  #  instead they find the memory filled with zero from 0x2.
-  #  The value should be a multiple of 4KB.
-  #  The range should be below the EBDA reserved range from
-  #  (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
-  #  CONVENTIONAL_MEMORY_TOP.
-  gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemoryBase|0x6|UINT32|0x2d
-
-  ## Specify memory size with bytes for OPROM to find free memory.
-  #  The value should be a multiple of 4KB. And the range should be below the
-  #  EBDA reserved range from
-  #  (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
-  #  CONVENTIONAL_MEMORY_TOP.
-  gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemorySize|0x28000|UINT32|0x2e
-
-  ## Specify the end of address below 1MB for the OPROM.
-  #  The last shadowed OpROM should not exceed this address.
-  gUefiOvmfPkgTokenSpaceGuid.PcdEndOpromShadowAddress|0xd|UINT32|0x2f
-
-  ## Specify the low PMM (Post Memory Manager) size with bytes below 1MB.
-  #  The value should be a multiple of 4KB.
-  # @Prompt Low PMM (Post Memory Manager) Size
-  gUefiOvmfPkgTokenSpaceGuid.PcdLowPmmMemorySize|0x1|UINT32|0x30
-
-  ## Specify the high PMM (Post Memory Manager) size with bytes above 1MB.
-  #  The value should be a multiple of 4KB.
-  gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize|0x40|UINT32|0x31
-
   gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
   gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
 



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

[edk2-devel] [PATCH 18/37] OvmfPkg: remove gEfiIsaAcpiProtocolGuid

[Laszlo Ersek]

At this point, gEfiIsaAcpiProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosGuid
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Guid/LegacyBios.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

- PCDs:
  - PcdEbdaReservedMemorySize
  - PcdEndOpromShadowAddress
  - PcdHighPmmMemorySize
  - PcdLegacyBiosCacheLegacyRegion
  - PcdLowPmmMemorySize
  - PcdOpromReservedMemoryBase
  - PcdOpromReservedMemorySize

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec|   1 -
 OvmfPkg/Csm/Include/Protocol/IsaAcpi.h | 298 
 2 files changed, 299 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 0b616c30a4ef..de4b6fe5c02b 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -185,7 +185,6 @@ [Protocols]
   gIoMmuAbsentProtocolGuid  = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
   gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
   gEfiFirmwareVolumeProtocolGuid= {0x389F751F, 0x1838, 0x4388, {0x83, 
0x90, 0xcd, 0x81, 0x54, 0xbd, 0x27, 0xf8}}
-  gEfiIsaAcpiProtocolGuid   = {0x64a892dc, 0x5561, 0x4536, {0x92, 
0xc7, 0x79, 0x9b, 0xfc, 0x18, 0x33, 0x55}}
   gEfiLegacyBiosProtocolGuid= {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
   gEfiLegacyBiosPlatformProtocolGuid= {0x783658a3, 0x4172, 0x4421, {0xa2, 
0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
   gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
diff --git a/OvmfPkg/Csm/Include/Protocol/IsaAcpi.h 
b/OvmfPkg/Csm/Include/Protocol/IsaAcpi.h
deleted file mode 100644
index afb415a388ab..
--- a/OvmfPkg/Csm/Include/Protocol/IsaAcpi.h
+++ /dev/null
@@ -1,298 +0,0 @@
-/** @file
-  EFI ISA ACPI Protocol is used to enumerate and manage all the ISA 
controllers on
-  the platform's ISA Bus.
-
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef __ISA_ACPI_H_
-#define __ISA_ACPI_H_
-
-///
-/// Global ID for the EFI ISA ACPI Protocol.
-///
-#define EFI_ISA_ACPI_PROTOCOL_GUID \
-  { \
-0x64a892dc, 0x5561, 0x4536, { 0x92, 0xc7, 0x79, 0x9b, 0xfc, 0x18, 0x33, 
0x55 } \
-  }
-
-///
-/// Forward declaration fo the EFI ISA ACPI Protocol
-///
-typedef struct _EFI_ISA_ACPI_PROTOCOL EFI_ISA_ACPI_PROTOCOL;
-
-///
-/// ISA ACPI Protocol interrupt resource attributes.
-///
-#define EFI_ISA_ACPI_IRQ_TYPE_HIGH_TRUE_EDGE_SENSITIVE   0x01   ///< Edge 
triggered interrupt on a rising edge.
-#define EFI_ISA_ACPI_IRQ_TYPE_LOW_TRUE_EDGE_SENSITIVE0x02   ///< Edge 
triggered interrupt on a falling edge.
-#define EFI_ISA_ACPI_IRQ_TYPE_HIGH_TRUE_LEVEL_SENSITIVE  0x04   ///< Level 
sensitive interrupt active high.
-#define EFI_ISA_ACPI_IRQ_TYPE_LOW_TRUE_LEVEL_SENSITIVE   0x08   ///< Level 
sensitive interrupt active low.
-
-///
-/// ISA ACPI Protocol DMA resource attributes.
-///
-#define EFI_ISA_ACPI_DMA_SPEED_TYPE_MASK 0x03   ///< Bit mask 
of supported DMA speed attributes.
-#define EFI_ISA_ACPI_DMA_SPEED_TYPE_COMPATIBILITY0x00   ///< ISA 
controller supports compatibility mode DMA transfers.
-#define EFI_ISA_ACPI_DMA_SPEED_TYPE_A0x01   ///< ISA 
controller supports type A DMA transfers.
-#define EFI_ISA_ACPI_DMA_SPEED_TYPE_B0x02   ///< ISA 
controller supports type B DMA transfers.
-#define EFI_ISA_ACPI_DMA_SPEED_TYPE_F0x03   ///< ISA 
controller supports type F DMA transfers.
-#define EFI_ISA_ACPI_DMA_COUNT_BY_BYTE   0x04   ///< ISA 
controller increments DMA address by bytes (8-bit).
-#define EFI_ISA_ACPI_DMA_COUNT_BY_WORD   0x08   ///< ISA 
controller increments DMA address by words (16-bit).
-#define EFI_ISA_ACPI_DMA_BUS_MASTER  0x10   ///< ISA 
controller is a DMA bus master.
-#define EFI_ISA_ACPI_DMA_TRANSFER_TYPE_8_BIT 0x20   ///< ISA 
controller only supports 8-bit DMA transfers.
-#define EFI_ISA_ACPI_DMA_TRANSFER_TYPE_8_BIT_AND_16_BIT  0x40   ///< ISA 
controller both 8-bit and 16-bit DMA transfers.
-#define EFI_ISA_ACPI_DMA_TRANSFER_TYPE_16_BIT0x80   ///< ISA 
controller only supports 16-bit DMA transfers.
-
-///
-/// ISA ACPI Protocol MMIO resource attributes
-///
-#define EFI_ISA_ACPI_MEMORY_WIDTH_MASK  0x03///< Bit mask 
of

[edk2-devel] [PATCH 17/37] OvmfPkg: remove gEfiIsaIoProtocolGuid

[Laszlo Ersek]

At this point, gEfiIsaIoProtocolGuid is unused; remove it.

Recursively, this patch removes mentions of the following further CSM
resources from the source code:

- GUIDs (protocols or otherwise):
  - gEfiIsaAcpiProtocolGuid (by cutting the  link)

- headers:
  - Protocol/IsaAcpi.h

This changes the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiIsaAcpiProtocolGuid
  - gEfiLegacy8259ProtocolGuid
  - gEfiLegacyBiosGuid
  - gEfiLegacyBiosPlatformProtocolGuid
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyInterruptProtocolGuid

- headers:
  - FrameworkDxe.h
  - Guid/LegacyBios.h
  - Protocol/IsaAcpi.h
  - Protocol/Legacy8259.h
  - Protocol/LegacyBios.h
  - Protocol/LegacyBiosPlatform.h
  - Protocol/LegacyInterrupt.h

- PCDs:
  - PcdEbdaReservedMemorySize
  - PcdEndOpromShadowAddress
  - PcdHighPmmMemorySize
  - PcdLegacyBiosCacheLegacyRegion
  - PcdLowPmmMemorySize
  - PcdOpromReservedMemoryBase
  - PcdOpromReservedMemorySize

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec  |   1 -
 OvmfPkg/Csm/Include/Protocol/IsaIo.h | 356 
 2 files changed, 357 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index c77126ea0892..0b616c30a4ef 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -186,7 +186,6 @@ [Protocols]
   gEfiLegacy8259ProtocolGuid= {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
   gEfiFirmwareVolumeProtocolGuid= {0x389F751F, 0x1838, 0x4388, {0x83, 
0x90, 0xcd, 0x81, 0x54, 0xbd, 0x27, 0xf8}}
   gEfiIsaAcpiProtocolGuid   = {0x64a892dc, 0x5561, 0x4536, {0x92, 
0xc7, 0x79, 0x9b, 0xfc, 0x18, 0x33, 0x55}}
-  gEfiIsaIoProtocolGuid = {0x7ee2bd44, 0x3da0, 0x11d4, {0x9a, 
0x38, 0x0, 0x90, 0x27, 0x3f, 0xc1, 0x4d}}
   gEfiLegacyBiosProtocolGuid= {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
   gEfiLegacyBiosPlatformProtocolGuid= {0x783658a3, 0x4172, 0x4421, {0xa2, 
0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
   gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
diff --git a/OvmfPkg/Csm/Include/Protocol/IsaIo.h 
b/OvmfPkg/Csm/Include/Protocol/IsaIo.h
deleted file mode 100644
index 40a8171e95da..
--- a/OvmfPkg/Csm/Include/Protocol/IsaIo.h
+++ /dev/null
@@ -1,356 +0,0 @@
-/** @file
-  ISA I/O Protocol is used by ISA device drivers to perform I/O, MMIO and DMA
-  operations on the ISA controllers they manage.
-
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _EFI_ISA_IO_H_
-#define _EFI_ISA_IO_H_
-
-#include 
-
-///
-/// Global ID for the EFI_ISA_IO_PROTOCOL
-///
-#define EFI_ISA_IO_PROTOCOL_GUID \
-  { \
-0x7ee2bd44, 0x3da0, 0x11d4, { 0x9a, 0x38, 0x0, 0x90, 0x27, 0x3f, 0xc1, 
0x4d } \
-  }
-
-///
-/// Forward declaration for the EFI_ISA_IO_PROTOCOL.
-///
-typedef struct _EFI_ISA_IO_PROTOCOL EFI_ISA_IO_PROTOCOL;
-
-///
-/// Width of EFI_ISA_IO_PROTOCOL I/O Port and MMIO operations.
-///
-typedef enum {
-  EfiIsaIoWidthUint8 = 0,  ///< 8-bit operation.
-  EfiIsaIoWidthUint16, ///< 16-bit operation.
-  EfiIsaIoWidthUint32, ///< 32-bit operation
-  EfiIsaIoWidthReserved,
-  EfiIsaIoWidthFifoUint8,  ///< 8-bit FIFO operation.
-  EfiIsaIoWidthFifoUint16, ///< 16-bit FIFO operation.
-  EfiIsaIoWidthFifoUint32, ///< 32-bit FIFO operation.
-  EfiIsaIoWidthFifoReserved,
-  EfiIsaIoWidthFillUint8,  ///< 8-bit Fill operation.
-  EfiIsaIoWidthFillUint16, ///< 16-bit Fill operation.
-  EfiIsaIoWidthFillUint32, ///< 32-bit Fill operation.
-  EfiIsaIoWidthFillReserved,
-  EfiIsaIoWidthMaximum
-} EFI_ISA_IO_PROTOCOL_WIDTH;
-
-///
-/// Attributes for the EFI_ISA_IO_PROTOCOL common DMA buffer allocations.
-///
-#define EFI_ISA_IO_ATTRIBUTE_MEMORY_WRITE_COMBINE  0x080///< Map a memory 
range so write are combined.
-#define EFI_ISA_IO_ATTRIBUTE_MEMORY_CACHED 0x800///< Map a memory 
range so all read and write accesses are cached.
-#define EFI_ISA_IO_ATTRIBUTE_MEMORY_DISABLE0x1000   ///< Disable a 
memory range.
-
-///
-/// Channel attribute for EFI_ISA_IO_PROTOCOL slave DMA requests
-///
-#define EFI_ISA_IO_SLAVE_DMA_ATTRIBUTE_SPEED_COMPATIBLE  0x001   ///< Set the 
speed of the DMA transfer in compatible mode.
-#define EFI_ISA_IO_SLAVE_DMA_ATTRIBUTE_SPEED_A   0x002   ///< Not 
supported.
-#define EFI_ISA_IO_SLAVE_DMA_ATTRIBUTE_SPEED_B   0x004   ///< Not 
supported.
-#define EFI_ISA_IO_SLAVE_DMA_ATTRIBUTE_SPEED_C   0x008   ///< Not 
supported.
-#define EFI_ISA_IO_SLAVE_DMA_ATTRIBUTE_WIDTH_8   0x010   ///< Request 
8-bit DMA transfers.  Only available on channels 0..

[edk2-devel] [PATCH 14/37] Revert "OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled"

[Laszlo Ersek]

This reverts commit c7341877f69505e69acd199c84b6c09218058bfa.

That commit was a later (2019-06-26), heavier weight exclusion of 64-bit
BARs when a CSM was included, and is similarly superfluous now, so revert
it.

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 
 OvmfPkg/OvmfPkgX64.dsc | 4 
 2 files changed, 8 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 3a83418bdd4e..1f144b07a650 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -635,11 +635,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
-!ifdef $(CSM_ENABLE)
-  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0
-!else
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
-!endif
 
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index ab846e5324fa..ce932301aff1 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -653,11 +653,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
-!ifdef $(CSM_ENABLE)
-  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0
-!else
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
-!endif
 
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 



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

[edk2-devel] [PATCH 12/37] OvmfPkg: exclude LegacyBiosDxe

[Laszlo Ersek]

LegacyBiosDxe is the core CSM driver. It procudes
gEfiLegacyBiosProtocolGuid, on top of several smaller, more foundational
legacy BIOS protocols, whose drivers we've not excluded yet. In the course
of tearing down CSM support in (reverse) dependency order, exclude
LegacyBiosDxe at this point.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc | 1 -
 OvmfPkg/OvmfPkgIa32.dsc| 1 -
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 -
 OvmfPkg/OvmfPkgX64.dsc | 1 -
 OvmfPkg/OvmfXen.dsc| 1 -
 OvmfPkg/Bhyve/BhyveX64.fdf | 1 -
 OvmfPkg/OvmfPkgIa32.fdf| 1 -
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 -
 OvmfPkg/OvmfPkgX64.fdf | 1 -
 OvmfPkg/OvmfXen.fdf| 1 -
 10 files changed, 10 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index a328819a19b5..c938ed76ee92 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -764,7 +764,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-#  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 !ifdef $(CSM_ENABLE)
   OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6f6c7ac48ac5..3005ef771bea 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -891,7 +891,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
   OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1dc9de851388..3a83418bdd4e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -909,7 +909,6 @@ [Components.X64]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
   OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4be493e830d5..ab846e5324fa 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -977,7 +977,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
   OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 8823f28d7b3b..0e2548d964bc 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -700,7 +700,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
   OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf
index 13e66c7304d8..b465fea7c72d 100644
--- a/OvmfPkg/Bhyve/BhyveX64.fdf
+++ b/OvmfPkg/Bhyve/BhyveX64.fdf
@@ -296,7 +296,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-#INF  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 !ifdef $(CSM_ENABLE)
 INF  RuleOverride=CSM OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index d01bae02c39e..996c116e418a 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -327,7 +327,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-INF  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 INF  RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index ed2e4583f01a..36727965798e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -333,7 +333,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-INF  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 INF  RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 3ee7e1be9b19..1000707d8c9a 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -360,7 +360,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-INF  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 INF  RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 73388bc5a3bf..ce825b01b48b 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -336,7 +336,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-INF  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 INF  RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
 



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

[edk2-devel] [PATCH 13/37] OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence

[Laszlo Ersek]

The UEFI protocol database cannot contain gEfiLegacyBiosProtocolGuid any
longer, after excluding LegacyBiosDxe from the OVMF platforms. Therefore,
instruct PciBusDxe from IncompatiblePciDeviceSupportDxe to allocate 64-bit
BARs above 4 GB regardless of a CSM.

Regression test: in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR
degradation if there is no CSM", 2016-05-25), where we introduced
IncompatiblePciDeviceSupportDxe, we said, "By default, the PCI Bus driver
considers an option ROM reason enough for allocating the 64-bit MMIO BARs
in 32-bit address space". Therefore it suffices to verify the 64-bit BARs
of a device for which QEMU provides an option ROM. The simplest case is
the virtio-net-pci device. And indeed, with this patch applied, the log
contains:

> PciBus: Discovered PCI @ [04|00|00]  [VID = 0x1AF4, DID = 0x1041]
>BAR[1]: Type =  Mem32; Alignment = 0xFFF;Length = 0x1000;
> Offset = 0x14
>BAR[4]: Type = PMem64; Alignment = 0x3FFF;   Length = 0x4000;
> Offset = 0x20

This portion shows that Bus|Device|Function 04|00|00 is a (modern)
virito-net-pci device [VID = 0x1AF4, DID = 0x1041].

> PciBus: Resource Map for Bridge [00|01|03]
> Type =  Mem32; Base = 0x8120;   Length = 0x20;  Alignment = 
> 0x1F
>Base = Padding;  Length = 0x20;  Alignment = 0x1F
>Base = 0x8120;   Length = 0x1000;Alignment = 0xFFF;  Owner 
> = PCI [04|00|00:14]
> Type =  Mem32; Base = 0x81A43000;   Length = 0x1000;Alignment = 
> 0xFFF
> Type = PMem64; Base = 0x80020;  Length = 0x10;  Alignment = 
> 0xF
>Base = 0x80020;  Length = 0x4000;Alignment = 0x3FFF; Owner 
> = PCI [04|00|00:20]

This quote shows that 04|00|00 has a BAR at 0x8_0020_.

(It also shows that the device is behind a bridge (PCIe root port) whose
own BDF is 00|01|03.)

> [Security] 3rd party image[7CEEB418] can be loaded after EndOfDxe: 
> PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/Offset(0x10E00,0x273FF).
> None of Tcg2Protocol/CcMeasurementProtocol is installed.
> InstallProtocolInterface: [EfiLoadedImageProtocol] 7D2E5140
> Loading driver at 0x0007CA9F000 EntryPoint=0x0007CAA5447 1af41000.efi
> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7D5B2198

And this part finally shows that the iPXE option ROM for the device
(1af41000.efi) was detected and is loaded. (Same PCIe root port, and PCIe
root ports can only host a single device.)

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf |   5 
+-
 OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c   | 141 
+---
 2 files changed, 6 insertions(+), 140 deletions(-)

diff --git 
a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf 
b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
index ad38128fcbf9..b92662d0bb36 100644
--- a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
+++ b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
@@ -1,7 +1,7 @@
 ## @file
 # A simple DXE_DRIVER that causes the PCI Bus UEFI_DRIVER to allocate 64-bit
-# MMIO BARs above 4 GB, regardless of option ROM availability (as long as a CSM
-# is not present), conserving 32-bit MMIO aperture for 32-bit BARs.
+# MMIO BARs above 4 GB, regardless of option ROM availability, conserving 
32-bit
+# MMIO aperture for 32-bit BARs.
 #
 # Copyright (C) 2016, Red Hat, Inc.
 #
@@ -33,7 +33,6 @@ [LibraryClasses]
 
 [Protocols]
   gEfiIncompatiblePciDeviceSupportProtocolGuid ## SOMETIMES_PRODUCES
-  gEfiLegacyBiosProtocolGuid   ## NOTIFY
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size## CONSUMES
diff --git 
a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c 
b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
index 3092a174bc51..434cdca84b23 100644
--- a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
+++ b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
@@ -1,7 +1,7 @@
 /** @file
   A simple DXE_DRIVER that causes the PCI Bus UEFI_DRIVER to allocate 64-bit
-  MMIO BARs above 4 GB, regardless of option ROM availability (as long as a CSM
-  is not present), conserving 32-bit MMIO aperture for 32-bit BARs.
+  MMIO BARs above 4 GB, regardless of option ROM availability, conserving 
32-bit
+  MMIO aperture for 32-bit BARs.
 
   Copyright (C) 2016, Red Hat, Inc.
   Copyright (c) 2017, Intel Corporation. All rights reserved.
@@ -21,12 +21,6 @@
 #include 
 
 #include 
-#include 
-
-//
-// The Legacy BIOS protocol has been located.
-//
-STATIC BOOLEAN  mLegacyBiosInstalled;
 
 //
 // The protocol inte

[edk2-devel] [PATCH 11/37] OvmfPkg: remove Bios Video PCDs

[Laszlo Ersek]

PcdBiosVideoSetTextVgaModeEnable, PcdBiosVideoCheckVbeEnable and
PcdBiosVideoCheckVgaEnable are unused at this point, remove them.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosGuid
  - gEfiLegacyBiosProtocolGuid

- headers:
  - FrameworkDxe.h
  - Guid/LegacyBios.h
  - Protocol/LegacyBios.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec | 20 
 1 file changed, 20 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index c9f41c7ddea5..c77126ea0892 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -291,26 +291,6 @@ [PcdsFixedAtBuild]
   #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
   gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x5
 
-  ## Indicates if BiosVideo driver will switch to 80x25 Text VGA Mode when
-  #  exiting boot service.
-  #   TRUE  - Switch to Text VGA Mode.
-  #   FALSE - Does not switch to Text VGA Mode.
-  
gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoSetTextVgaModeEnable|FALSE|BOOLEAN|0x28
-
-  ## Indicates if BiosVideo driver will check for VESA BIOS Extension service
-  #  support.
-  #   TRUE  - Check for VESA BIOS Extension service.
-  #   FALSE - Does not check for VESA BIOS Extension service.
-  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVbeEnable|TRUE|BOOLEAN|0x29
-
-  ## Indicates if BiosVideo driver will check for VGA service support.
-  #  NOTE: If both PcdBiosVideoCheckVbeEnable and PcdBiosVideoCheckVgaEnable
-  #  are set to FALSE, that means Graphics Output protocol will not be
-  #  installed, the VGA miniport protocol will be installed instead.
-  #   TRUE  - Check for VGA service.
-  #   FALSE - Does not check for VGA service.
-  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVgaEnable|TRUE|BOOLEAN|0x2a
-
   ## Indicates if memory space for legacy region will be set as cacheable.
   #   TRUE  - Set cachebility for legacy region.
   #   FALSE - Does not set cachebility for legacy region.



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

[edk2-devel] [PATCH 10/37] OvmfPkg: remove gEfiVgaMiniPortProtocolGuid

[Laszlo Ersek]

At this point, gEfiVgaMiniPortProtocolGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosGuid
  - gEfiLegacyBiosProtocolGuid

- headers:
  - FrameworkDxe.h
  - Guid/LegacyBios.h
  - Protocol/LegacyBios.h

- PCDs:
  - PcdBiosVideoCheckVbeEnable
  - PcdBiosVideoCheckVgaEnable
  - PcdBiosVideoSetTextVgaModeEnable

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec|  1 -
 OvmfPkg/Csm/Include/Protocol/VgaMiniPort.h | 88 
 2 files changed, 89 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 19149dc9fec7..c9f41c7ddea5 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -190,7 +190,6 @@ [Protocols]
   gEfiLegacyBiosProtocolGuid= {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
   gEfiLegacyBiosPlatformProtocolGuid= {0x783658a3, 0x4172, 0x4421, {0xa2, 
0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
   gEfiLegacyInterruptProtocolGuid   = {0x31ce593d, 0x108a, 0x485d, {0xad, 
0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
-  gEfiVgaMiniPortProtocolGuid   = {0xc7735a2f, 0x88f5, 0x4882, {0xae, 
0x63, 0xfa, 0xac, 0x8c, 0x8b, 0x86, 0xb3}}
   gOvmfLoadedX86LinuxKernelProtocolGuid = {0xa3edc05d, 0xb618, 0x4ff6, {0x95, 
0x52, 0x76, 0xd7, 0x88, 0x63, 0x43, 0xc8}}
   gOvmfSevMemoryAcceptanceProtocolGuid  = {0xc5a010fe, 0x38a7, 0x4531, {0x8a, 
0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49}}
   gQemuAcpiTableNotifyProtocolGuid  = {0x928939b2, 0x4235, 0x462f, {0x95, 
0x80, 0xf6, 0xa2, 0xb2, 0xc2, 0x1a, 0x4f}}
diff --git a/OvmfPkg/Csm/Include/Protocol/VgaMiniPort.h 
b/OvmfPkg/Csm/Include/Protocol/VgaMiniPort.h
deleted file mode 100644
index fa023a2dfae4..
--- a/OvmfPkg/Csm/Include/Protocol/VgaMiniPort.h
+++ /dev/null
@@ -1,88 +0,0 @@
-/** @file
-  The VGA Mini Port Protocol used to set the text display mode of a VGA 
controller.
-
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef __VGA_MINI_PORT_H_
-#define __VGA_MINI_PORT_H_
-
-///
-/// Global ID for the EFI_VGA_MINI_PORT_PROTOCOL.
-///
-#define EFI_VGA_MINI_PORT_PROTOCOL_GUID \
-  { \
-0xc7735a2f, 0x88f5, 0x4882, {0xae, 0x63, 0xfa, 0xac, 0x8c, 0x8b, 0x86, 
0xb3 } \
-  }
-
-///
-/// Forward declaration for the EFI_VGA_MINI_PORT_PROTOCOL.
-///
-typedef struct _EFI_VGA_MINI_PORT_PROTOCOL EFI_VGA_MINI_PORT_PROTOCOL;
-
-/**
-  Sets the text display mode of a VGA controller.
-
-  Sets the text display mode of the VGA controller to the mode specified by
-  ModeNumber.  A ModeNumber of 0 is a request for an 80x25 text mode.  A
-  ModeNumber of 1 is a request for an 80x50 text mode.  If ModeNumber is 
greater
-  than MaxModeNumber, then EFI_UNSUPPORTED is returned.  If the VGA controller
-  is not functioning properly, then EFI_DEVICE_ERROR is returned.  If the VGA
-  controller is successfully set to the mode number specified by ModeNumber, 
then
-  EFI_SUCCESS is returned.
-
-  @param[in] This A pointer to the EFI_VGA_MINI_PORT_PROTOCOL instance.
-  @param[in] ModeNumber   The requested mode number.  0 for 80x25.  1 for 80x5.
-
-  @retval EFI_SUCCESSThe mode number was set.
-  @retval EFI_UNSUPPORTEDThe mode number specified by ModeNumber is not 
supported.
-  @retval EFI_DEVICE_ERROR   The device is not functioning properly.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *EFI_VGA_MINI_PORT_SET_MODE)(
-  IN EFI_VGA_MINI_PORT_PROTOCOL  *This,
-  IN UINTNModeNumber
-  );
-
-struct _EFI_VGA_MINI_PORT_PROTOCOL {
-  EFI_VGA_MINI_PORT_SET_MODESetMode;
-  ///
-  /// MMIO base address of the VGA text mode framebuffer.  Typically set to 
0xB8000.
-  ///
-  UINT64VgaMemoryOffset;
-  ///
-  /// I/O Port address for the VGA CRTC address register. Typically set to 
0x3D4.
-  ///
-  UINT64CrtcAddressRegisterOffset;
-  ///
-  /// I/O Port address for the VGA CRTC data register.  Typically set to 0x3D5.
-  ///
-  UINT64CrtcDataRegisterOffset;
-  ///
-  /// PCI Controller MMIO BAR index of the VGA text mode frame buffer.  
Typically
-  /// set to EFI_PCI_IO_PASS_THROUGH_BAR
-  ///
-  UINT8 VgaMemoryBar;
-  ///
-  /// PCI Controller I/O BAR index of the VGA CRTC address register.  Typically
-  /// set to EFI_PCI_IO_PASS_THROUGH_BAR
-  ///
-  UINT8 CrtcAddressRegisterBar;
-  ///
-  /// PCI Controller I/O BAR index of the VGA CRTC data register.  Typically 
set
-  /// to EFI_PCI_IO_PASS_THROUGH_BAR
-  ///
-  UINT8 CrtcDataRegisterBar;
-  ///
-  /// The maximum number of text modes that this VGA controller supports.
-  ///
-  UINT8 MaxMode;
-};
-
-extern EFI_GUID

[edk2-devel] [PATCH 08/37] OvmfPkg: exclude the CSM-based VideoDxe driver

[Laszlo Ersek]

The CSM-based VideoDxe driver is a special UEFI_DRIVER module that both
follows and doesn't follow the UEFI driver model.

Namely, in the Supported and Start members of its Driver Binding Protocol
instance, it consumes the Legacy Bios Protocol directly from the UEFI
protocol database, as opposed to (only) opening protocols on the handle
that it is supposed to bind.

Furthermore, the driver "marks" its own image handle with the
NULL-interface "Legacy Bios" (pseudo-protocol) GUID, in order to "inform
back" the provider of the Legacy Bios Protocol, i.e., LegacyBiosDxe, that
VideoDxe is a "BIOS Thunk Driver" in the system.

Quoting "OvmfPkg/Csm/Include/Guid/LegacyBios.h", such a driver follows the
UEFI Driver Model, but still uses the Int86() or FarCall() services of the
Legacy Bios Protocol as the basis for the UEFI protocol it produces.

In a sense, there is a circular dependency between VideoDxe and
LegacyBiosDxe; each knows about the other. However, VideoDxe is a
UEFI_DRIVER, while LegacyBiosDxe is a platform DXE_DRIVER with a very long
DEPEX. Therefore, for keeping dependencies conceptually intact, first
exclude VideoDxe from the OVMF platforms. Always include the
hypervisor-specific real UEFI video driver.

--*--

Note that the pathname
"IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf" in the bhyve
platform DSC and FDF files is bogus anyway.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc| 6 --
 OvmfPkg/IntelTdx/IntelTdxX64.dsc  | 2 --
 OvmfPkg/OvmfPkgIa32.dsc   | 6 --
 OvmfPkg/OvmfPkgIa32X64.dsc| 6 --
 OvmfPkg/OvmfPkgX64.dsc| 6 --
 OvmfPkg/OvmfXen.dsc   | 4 
 OvmfPkg/Bhyve/BhyveX64.fdf| 3 ---
 OvmfPkg/OvmfPkgIa32.fdf   | 6 ++
 OvmfPkg/OvmfPkgIa32X64.fdf| 6 ++
 OvmfPkg/OvmfPkgX64.fdf| 6 ++
 OvmfPkg/OvmfXen.fdf   | 1 -
 OvmfPkg/Bhyve/BhyveRfbDxe/GopDriver.c | 2 --
 12 files changed, 6 insertions(+), 48 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 073bf541661c..a328819a19b5 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -764,12 +764,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!ifdef $(CSM_ENABLE)
-  IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
-
-  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-  }
-!endif
 #  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
 !ifdef $(CSM_ENABLE)
   OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 5513b7763774..0177c174c2ab 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -684,9 +684,7 @@ [Components]
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
-!ifndef $(CSM_ENABLE)
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
-!endif
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
 
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index a2ac18a4a766..6f6c7ac48ac5 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -843,9 +843,7 @@ [Components]
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
-!ifndef $(CSM_ENABLE)
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
-!endif
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
 
@@ -893,10 +891,6 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
-
-  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-  }
   OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
   OvmfPkg/Csm/Csm16/Csm16.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a935ca2eb6ac..1dc9de851388 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -861,9 +861,7 @@ [Components.X64]
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 
-!ifndef $(CSM_ENABLE)
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
-!endif
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
 
@@ -911,10 +909,6 @@ [Components.X64]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
 !ifdef $(CSM_ENABLE)
-  OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
-
-  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-  }
   OvmfPkg/Csm/LegacyBiosDxe/LegacyB

[edk2-devel] [PATCH 06/37] OvmfPkg: remove LegacyBootMaintUiLib

[Laszlo Ersek]

LegacyBootMaintUiLib is not used by any platform at this point, remove it.

This patch removes mentions of the following CSM resources from the source
code:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyDevOrderVariableGuid

- headers:
  - Guid/LegacyDevOrder.h
  - Protocol/LegacyBios.h

which extends the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyDevOrderVariableGuid

- headers:
  - Guid/LegacyDevOrder.h
  - Protocol/LegacyBios.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.uni |   20 -
 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiStrings.uni |   43 -
 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf |   62 -
 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUi.h  |  242 
 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h   |   73 -
 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUi.c  | 1500 

 OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr |   67 -
 7 files changed, 2007 deletions(-)

diff --git a/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.uni 
b/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.uni
deleted file mode 100644
index f29e1449a749..
--- a/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.uni
+++ /dev/null
@@ -1,20 +0,0 @@
-// /** @file
-// Legacy Boot Maintenance UI module is library for BDS phase.
-//
-// Legacy Boot Maintenance UI module is library for BDS phase.
-//
-// Copyright (c) 2015, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-#string STR_MODULE_ABSTRACT
-#language en-US
-"Legacy Boot Maintenance UI module is library for BDS phase."
-
-#string STR_MODULE_DESCRIPTION
-#language en-US
-"Legacy Boot Maintenance UI module is library for BDS phase."
-
-
diff --git a/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiStrings.uni 
b/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiStrings.uni
deleted file mode 100644
index 8d40ca1af1c0..
--- a/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiStrings.uni
+++ /dev/null
@@ -1,43 +0,0 @@
-///** @file
-//
-//String definitions for Legacy Boot Maintainece Ui.
-//
-//  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
-//  SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-//**/
-
-/=#
-
-#langdef   en-US "English"
-#langdef   fr-FR "Français"
-
-#string STR_LEGACY_BOOT_PROMPT #language en-US  "Legacy Boot Options 
Menu"
-   #language fr-FR  "Legacy Boot Options 
Menu"
-#string STR_LEGACY_BOOT_HELP   #language en-US  "Manager legacy boot 
options in this driver."
-   #language fr-FR  "Manager legacy boot 
options in this driver."
-#string STR_FORM_FLOPPY_BOOT_TITLE #language en-US  "Set Legacy Floppy 
Driver Order"
-   #language fr-FR  "Set Legacy Floppy 
Driver Order"
-#string STR_FORM_FLOPPY_BOOT_HELP  #language en-US  "Set Legacy Floppy 
Driver Order."
-   #language fr-FR  "Set Legacy Floppy 
Driver Order."
-#string STR_FORM_HARDDISK_BOOT_TITLE   #language en-US  "Set Legacy HARDDISK 
Driver Order"
-   #language fr-FR  "Set Legacy HARDDISK 
Driver Order"
-#string STR_FORM_HARDDISK_BOOT_HELP#language en-US  "Set Legacy HARDDISK 
Driver Order."
-   #language fr-FR  "Set Legacy HARDDISK 
Driver Order."
-#string STR_FORM_CDROM_BOOT_TITLE  #language en-US  "Set Legacy CDROM 
Driver Order"
-   #language fr-FR  "Set Legacy CDROM 
Driver Order"
-#string STR_FORM_CDROM_BOOT_HELP   #language en-US  "Set Legacy CDROM 
Driver Order."
-   #language fr-FR  "Set Legacy CDROM 
Driver Order."
-#string STR_FORM_NET_BOOT_TITLE#language en-US  "Set Legacy NET Driver 
Order"
-   #language fr-FR  "Set Legacy NET Driver 
Order"
-#string STR_FORM_NET_BOOT_HELP #language en-US  "Set Legacy NET Driver 
Order."
-   #language fr-FR  "Set Legacy NET Driver 
Order."
-#string STR_FORM_BEV_BOOT_TITLE#language en-US  "Set Legacy BEV Driver 
Order"
-   #language fr-FR  "Set Legacy BEV Driver 
Order"
-#string STR_FORM_BEV_BOOT_HELP #language en-US  "Set Legacy BEV Driver 
Order."

[edk2-devel] [PATCH 07/37] OvmfPkg: remove gEfiLegacyDevOrderVariableGuid

[Laszlo Ersek]

At this point, gEfiLegacyDevOrderVariableGuid is unused; remove it.

This shrinks the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosProtocolGuid

- headers:
  - Protocol/LegacyBios.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec   |  1 -
 OvmfPkg/Csm/Include/Guid/LegacyDevOrder.h | 39 
 2 files changed, 40 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 74cc870cbed3..19149dc9fec7 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -156,7 +156,6 @@ [Guids]
   gRootBridgesConnectedEventGroupGuid   = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
   gMicrosoftVendorGuid  = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 
0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
   gEfiLegacyBiosGuid= {0x2E3044AC, 0x879F, 0x490F, {0x97, 
0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
-  gEfiLegacyDevOrderVariableGuid= {0xa56074db, 0x65fe, 0x45f7, {0xbd, 
0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
   gQemuKernelLoaderFsMediaGuid  = {0x1428f772, 0xb64a, 0x441e, {0xb8, 
0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
   gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 
0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
   gConfidentialComputingSecretGuid  = {0xadf956ad, 0xe98c, 0x484c, {0xae, 
0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
diff --git a/OvmfPkg/Csm/Include/Guid/LegacyDevOrder.h 
b/OvmfPkg/Csm/Include/Guid/LegacyDevOrder.h
deleted file mode 100644
index 4446b005cb12..
--- a/OvmfPkg/Csm/Include/Guid/LegacyDevOrder.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/** @file
-  Guid of a NV Variable which store the information about the
-  FD/HD/CD/NET/BEV order.
-
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef __LEGACY_DEV_ORDER_VARIABLE_GUID_H__
-#define __LEGACY_DEV_ORDER_VARIABLE_GUID_H__
-
-///
-/// Name and Guid of a NV Variable which stores the information about the
-/// FD/HD/CD/NET/BEV order
-///
-#define EFI_LEGACY_DEV_ORDER_VARIABLE_GUID \
-  { \
-  0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52} 
\
-  }
-
-typedef UINT8 BBS_TYPE;
-
-#pragma pack(1)
-typedef struct {
-  BBS_TYPEBbsType;
-  ///
-  /// Length = sizeof (UINT16) + sizeof (Data)
-  ///
-  UINT16  Length;
-  UINT16  Data[1];
-} LEGACY_DEV_ORDER_ENTRY;
-#pragma pack()
-
-#define VAR_LEGACY_DEV_ORDER  L"LegacyDevOrder"
-
-extern EFI_GUID  gEfiLegacyDevOrderVariableGuid;
-
-#endif



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

[edk2-devel] [PATCH 05/37] OvmfPkg: unplug LegacyBootMaintUiLib from UiApp

[Laszlo Ersek]

LegacyBootMaintUiLib registers a form (HII Config Access Protocol
instance) with UiApp, for configuring legacy boot options; stop plugging
it into UiApp.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc | 3 ---
 OvmfPkg/OvmfPkgIa32.dsc| 3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
 OvmfPkg/OvmfPkgX64.dsc | 3 ---
 OvmfPkg/OvmfXen.dsc| 3 ---
 5 files changed, 15 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 4d4bb2a58708..073bf541661c 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -675,9 +675,6 @@ [Components]
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
-!endif
   }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/Virtio10Dxe/Virtio10.inf
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index ca09a9302e02..a2ac18a4a766 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -790,9 +790,6 @@ [Components]
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
-!endif
   }
   OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1ff2213dc4a1..a935ca2eb6ac 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -808,9 +808,6 @@ [Components.X64]
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
-!endif
   }
   OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0bd497c64be4..5f95d9ca3d36 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -876,9 +876,6 @@ [Components]
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
-!endif
   }
   OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
 
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 8573052dc9c5..dee2349e57f0 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -604,9 +604,6 @@ [Components]
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
-!ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
-!endif
   }
   OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
 



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

[edk2-devel] [PATCH 04/37] OvmfPkg: remove LegacyBootManagerLib

[Laszlo Ersek]

LegacyBootManagerLib is not used by any platform at this point, remove it.

This patch removes mentions of the following CSM resources from the source
code:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyDevOrderVariableGuid

- headers:
  - Guid/LegacyDevOrder.h
  - Protocol/LegacyBios.h

which extends the list of resources scheduled for removal to:

- GUIDs (protocols or otherwise):
  - gEfiLegacyBiosProtocolGuid
  - gEfiLegacyDevOrderVariableGuid

- headers:
  - Guid/LegacyDevOrder.h
  - Protocol/LegacyBios.h

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.uni |   20 -
 OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf |   57 -
 OvmfPkg/Csm/LegacyBootManagerLib/InternalLegacyBm.h   |   60 -
 OvmfPkg/Csm/LegacyBootManagerLib/LegacyBm.c   | 1573 

 4 files changed, 1710 deletions(-)

diff --git a/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.uni 
b/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.uni
deleted file mode 100644
index da2915a9a391..
--- a/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.uni
+++ /dev/null
@@ -1,20 +0,0 @@
-// /** @file
-// Legacy Boot Manager module is library for BDS phase.
-//
-// Legacy Boot Manager module is library for BDS phase.
-//
-// Copyright (c) 2015, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-#string STR_MODULE_ABSTRACT
-#language en-US
-"Legacy Boot Manager module is library for BDS phase."
-
-#string STR_MODULE_DESCRIPTION
-#language en-US
-"Legacy Boot Manager module is library for BDS phase."
-
-
diff --git a/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf 
b/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
deleted file mode 100644
index e43351cf959f..
--- a/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
+++ /dev/null
@@ -1,57 +0,0 @@
-## @file
-#  Legacy Boot Manager module is library for BDS phase.
-#
-#  Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = LegacyBootManagerLib
-  MODULE_UNI_FILE= LegacyBootManagerLib.uni
-  FILE_GUID  = D1BBB810-6A9E-40E0-87CB-65EAD2AA2A09
-  MODULE_TYPE= DXE_DRIVER
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = NULL|DXE_DRIVER UEFI_APPLICATION
-  CONSTRUCTOR= LegacyBootManagerLibConstructor
-
-#
-# The following information is for reference only and not required by the 
build tools.
-#
-#  VALID_ARCHITECTURES   = IA32 X64 EBC
-#
-
-[Sources]
-  LegacyBm.c
-  InternalLegacyBm.h
-
-[Packages]
-  MdePkg/MdePkg.dec
-  MdeModulePkg/MdeModulePkg.dec
-  OvmfPkg/OvmfPkg.dec
-
-[LibraryClasses]
-  BaseLib
-  BaseMemoryLib
-  UefiBootServicesTableLib
-  UefiRuntimeServicesTableLib
-  DevicePathLib
-  MemoryAllocationLib
-  UefiLib
-  DebugLib
-  PrintLib
-  PerformanceLib
-  UefiBootManagerLib
-
-[Guids]
-  gEfiGlobalVariableGuid## SOMETIMES_PRODUCES ## 
Variable:L"Boot" (Boot option variable)
-## SOMETIMES_CONSUMES ## 
Variable:L"BootOrder" (The boot option array)
-  gEfiLegacyDevOrderVariableGuid
-
-[Protocols]
-  gEfiLegacyBiosProtocolGuid## SOMETIMES_CONSUMES
-
-[FeaturePcd]
-
-[Pcd]
diff --git a/OvmfPkg/Csm/LegacyBootManagerLib/InternalLegacyBm.h 
b/OvmfPkg/Csm/LegacyBootManagerLib/InternalLegacyBm.h
deleted file mode 100644
index 8dd8b884d375..
--- a/OvmfPkg/Csm/LegacyBootManagerLib/InternalLegacyBm.h
+++ /dev/null
@@ -1,60 +0,0 @@
-/** @file
-
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _INTERNAL_LEGACY_BM_H_
-#define _INTERNAL_LEGACY_BM_H_
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#pragma pack(1)
-typedef struct {
-  UINT16BbsIndex;
-} LEGACY_BM_BOOT_OPTION_BBS_DATA;
-#pragma pack()
-
-/**
-  Boot the legacy system with the boot option.
-
-  @param  BootOption The legacy boot option which have BBS device path
- On return, BootOption->Status contains the boot status.
- EFI_UNSUPPORTEDThere is no legacybios protocol, do 
not support
-legacy boot.
- EFI_STATUS The status of LegacyBios->LegacyBoot 
().
-**/
-VOID
-EFIAPI
-LegacyBmBoot (
-  IN  EFI_BOOT_MANAGER_LOAD_OPTION  *BootOption
-

[edk2-devel] [PATCH 03/37] OvmfPkg: unplug LegacyBootManagerLib from BdsDxe and UiApp

[Laszlo Ersek]

Don't register the LegacyBmRefreshAllBootOption() and LegacyBmBoot()
functions in BdsDxe and UiApp.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc | 2 --
 OvmfPkg/OvmfPkgIa32.dsc| 2 --
 OvmfPkg/OvmfPkgIa32X64.dsc | 2 --
 OvmfPkg/OvmfPkgX64.dsc | 2 --
 OvmfPkg/OvmfXen.dsc| 2 --
 5 files changed, 10 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 6965c90508f2..4d4bb2a58708 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -667,7 +667,6 @@ [Components]
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
   NULL|OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
 !endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
@@ -677,7 +676,6 @@ [Components]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
 !ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index ea513eb2e951..ca09a9302e02 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -782,7 +782,6 @@ [Components]
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 !ifdef $(CSM_ENABLE)
   NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
 !endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
@@ -792,7 +791,6 @@ [Components]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
 !ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index bb078ed89c14..1ff2213dc4a1 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -800,7 +800,6 @@ [Components.X64]
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 !ifdef $(CSM_ENABLE)
   NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
 !endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
@@ -810,7 +809,6 @@ [Components.X64]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
 !ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fb816c722c40..0bd497c64be4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -868,7 +868,6 @@ [Components]
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 !ifdef $(CSM_ENABLE)
   NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
 !endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
@@ -878,7 +877,6 @@ [Components]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
 !ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 2fbab39b485d..8573052dc9c5 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -596,7 +596,6 @@ [Components]
 
 !ifdef $(CSM_ENABLE)
   NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
 !endif
   }
   MdeModulePkg/Logo/LogoDxe.inf
@@ -606,7 +605,6 @@ [Components]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
 !ifdef $(CSM_ENABLE)
-  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }



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

[edk2-devel] [PATCH 02/37] OvmfPkg: remove PcdCsmEnable

[Laszlo Ersek]

PcdCsmEnable was introduced in commits 50f911d25d39 ("OvmfPkg: introduce
PcdCsmEnable feature flag", 2020-02-05) and 75839f977d37
("OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)",
2020-02-05). Remove it, and substitute constant FALSE wherever it has been
evaluated thus far.

Regression test: after building OVMF IA32X64 with -D SMM_REQUIRE, and
booting it on Q35, the log still contains

> Q35SmramAtDefaultSmbaseInitialization: SMRAM at default SMBASE found

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec |  5 ---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc|  1 -
 OvmfPkg/OvmfPkgIa32.dsc |  1 -
 OvmfPkg/OvmfPkgIa32X64.dsc  |  1 -
 OvmfPkg/OvmfPkgX64.dsc  |  1 -
 OvmfPkg/OvmfXen.dsc |  1 -
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 -
 OvmfPkg/PlatformPei/MemDetect.c | 36 +++-
 8 files changed, 13 insertions(+), 34 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index e3861e5c1b39..74cc870cbed3 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -497,8 +497,3 @@ [PcdsFeatureFlag]
 
   ## This feature flag indicates the firmware build supports secure boot.
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootSupported|FALSE|BOOLEAN|0x6d
-
-  ## Informs modules (including pre-DXE-phase modules) whether the platform
-  #  firmware contains a CSM (Compatibility Support Module).
-  #
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|FALSE|BOOLEAN|0x35
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 669d3343b199..5513b7763774 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -377,7 +377,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootSupported|TRUE
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 9b1117ac51f7..ea513eb2e951 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -472,7 +472,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 22f9d903dcd5..bb078ed89c14 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -479,7 +479,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index cf232e2b95b0..fb816c722c40 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -498,7 +498,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index e83a6497a793..2fbab39b485d 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -364,7 +364,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
 !error "CSM is being torn down"
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 
 [PcdsFixedAtBuild]
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 3934aeed9514..ad52be306560 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -133,7 +133,6 @@ [FixedPcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
 
 [FeaturePcd]
-  gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Ppis]
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 0c755c4940bb..493cb1fbeb01 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -89,32 +89,22 @@ Q35SmramAtDefaultSmbaseInitialization (
   )
 {
   RETURN_STATUS  PcdStatus;
+  UINTN  CtlReg;
+  UINT8  CtlRegVal;
 
   ASSERT (PlatformInfoHob->HostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID);
 
-  PlatformInfoHob->Q35SmramAtDefaultSmbase = FALSE;
-  if (FeaturePcdGet (PcdCsmEnable)) {
-DEBUG ((
-  DEBUG_INFO,
-  "%a: SMRAM at default SMBASE not checked due to CSM\

[edk2-devel] [PATCH 01/37] OvmfPkg: cripple CSM_ENABLE macro

[Laszlo Ersek]

We're going to gradually tear down and remove the Compatibility Support
Module (CSM) in OvmfPkg (due to it having no maintainer). Start by making
all platforms that have thus far accepted "-D CSM_ENABLE" reject that
macro, so that mid-series, the partially removed infrastructure cannot be
built or booted.

Insert an !error directive in each DSC file's first "!ifdef $(CSM_ENABLE)"
conditional.

At the end of the series, the !error directive introduced in this patch
will be removed.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32.dsc  | 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
 OvmfPkg/OvmfPkgX64.dsc   | 1 +
 OvmfPkg/OvmfXen.dsc  | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 6693342c5f6e..6965c90508f2 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -665,6 +665,7 @@ [Components]
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
 !ifdef $(CSM_ENABLE)
+!error "CSM is being torn down"
   NULL|OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf
   NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
 !endif
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 182ec3705dd3..669d3343b199 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -376,6 +376,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
+!error "CSM is being torn down"
   gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SECURE_BOOT_ENABLE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index ed3a19feebe6..9b1117ac51f7 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -471,6 +471,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
+!error "CSM is being torn down"
   gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 16ca139b2973..22f9d903dcd5 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -478,6 +478,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
+!error "CSM is being torn down"
   gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index dc1a0942aa8b..cf232e2b95b0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -497,6 +497,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
+!error "CSM is being torn down"
   gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 0063245b5659..e83a6497a793 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -363,6 +363,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 !ifdef $(CSM_ENABLE)
+!error "CSM is being torn down"
   gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
 !endif
 



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

[edk2-devel] [PATCH 00/37] OvmfPkg: remove the CSM (after edk2-stable202311)

[Laszlo Ersek]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
CI: https://github.com/tianocore/edk2/pull/5031 (@ 961d5add9f03)

Remove the Compatibility Support Module (CSM) from OVMF (after
edk2-stable202311).

Modify the following platforms:

  OvmfPkg/AmdSev/AmdSevX64.dsc
  OvmfPkg/Bhyve/BhyveX64.dsc
  OvmfPkg/CloudHv/CloudHvX64.dsc
  OvmfPkg/IntelTdx/IntelTdxX64.dsc
  OvmfPkg/Microvm/MicrovmX64.dsc
  OvmfPkg/OvmfPkgIa32.dsc
  OvmfPkg/OvmfPkgIa32X64.dsc
  OvmfPkg/OvmfPkgX64.dsc
  OvmfPkg/OvmfXen.dsc

Each of those platforms builds at every stage of the series.

Follow a gradual approach. Peel off CSM components in (reverse)
dependency order:

- exclude a high-level CSM component (library or driver) from the OVMF
  platforms, without breaking dependencies of low-level components;

- delete the high-level component from OvmfPkg;

- add, to a removal queue, any source code artifacts (protocols, GUIDs,
  headers, PCDs) that the high-level component's deletion
  *unreferences*;

- delete all entries of the removal queue (protocols, GUIDs, headers,
  PCDs) from the edk2 source tree that are now completely unreferenced
  (... and extend the removal queue recursively, if needed);

- advance to the next component that now qualifies as "high-level"
  (because nothing consumes the services it provides any longer), and
  exclude that one.

Regression-test the traditional platforms as needed; see the notes in
the following patches:

- OvmfPkg: remove PcdCsmEnable
- OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence
- OvmfPkg: exclude 8254TimerDxe

Cc: Anatol Belski 
Cc: Andrei Warkentin 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Corvin Köhne 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: Jianyong Wu 
Cc: Jiewen Yao 
Cc: Michael Roth 
Cc: Min Xu 
Cc: Rebecca Cran 
Cc: Sunil V L 
Cc: Tom Lendacky 

Thanks
Laszlo

Laszlo Ersek (37):
  OvmfPkg: cripple CSM_ENABLE macro
  OvmfPkg: remove PcdCsmEnable
  OvmfPkg: unplug LegacyBootManagerLib from BdsDxe and UiApp
  OvmfPkg: remove LegacyBootManagerLib
  OvmfPkg: unplug LegacyBootMaintUiLib from UiApp
  OvmfPkg: remove LegacyBootMaintUiLib
  OvmfPkg: remove gEfiLegacyDevOrderVariableGuid
  OvmfPkg: exclude the CSM-based VideoDxe driver
  OvmfPkg: remove Csm/BiosThunk/VideoDxe
  OvmfPkg: remove gEfiVgaMiniPortProtocolGuid
  OvmfPkg: remove Bios Video PCDs
  OvmfPkg: exclude LegacyBiosDxe
  OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence
  Revert "OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled"
  OvmfPkg: remove LegacyBiosDxe
  OvmfPkg: exclude NullMemoryTestDxe driver
  OvmfPkg: remove gEfiIsaIoProtocolGuid
  OvmfPkg: remove gEfiIsaAcpiProtocolGuid
  OvmfPkg: remove gEfiLegacyBiosGuid
  OvmfPkg: remove LegacyBiosDxe PCDs
  OvmfPkg: unplug CsmSupportLib from BdsDxe
  OvmfPkg: remove CsmSupportLib
  OvmfPkg: remove gEfiFirmwareVolumeProtocolGuid
  OvmfPkg: remove gEfiLegacyBiosPlatformProtocolGuid
  OvmfPkg: remove gEfiLegacyBiosProtocolGuid
  OvmfPkg: remove gEfiLegacyInterruptProtocolGuid
  OvmfPkg: remove 
  OvmfPkg: exclude Csm16.inf / Csm16.bin
  OvmfPkg: remove Rule.Common.USER_DEFINED.CSM from all FDF files
  OvmfPkg: remove Csm16
  OvmfPkg: exclude 8254TimerDxe
  OvmfPkg: remove 8254TimerDxe
  OvmfPkg: exclude 8259InterruptControllerDxe
  OvmfPkg: remove 8259InterruptControllerDxe
  OvmfPkg: remove gEfiLegacy8259ProtocolGuid
  OvmfPkg: remove Pcd8259LegacyModeEdgeLevel and Pcd8259LegacyModeMask
  OvmfPkg: remove CSM_ENABLE build macro

 OvmfPkg/8254TimerDxe/8254Timer.inf   |   
43 -
 OvmfPkg/8254TimerDxe/Timer.c |  
406 ---
 OvmfPkg/8254TimerDxe/Timer.h |  
186 --
 OvmfPkg/8254TimerDxe/Timer.uni   |   
16 -
 OvmfPkg/8254TimerDxe/TimerExtra.uni  |   
14 -
 OvmfPkg/8259InterruptControllerDxe/8259.c|  
622 
 OvmfPkg/8259InterruptControllerDxe/8259.h|  
218 --
 OvmfPkg/8259InterruptControllerDxe/8259.inf  |   
45 -
 OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni|   
16 -
 OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni   |   
14 -
 OvmfPkg/AmdSev/AmdSevX64.dsc |
4 -
 OvmfPkg/AmdSev/AmdSevX64.fdf |
1 -
 OvmfPkg/Bhyve/BhyveRfbDxe/GopDriver.c|
2 -
 OvmfPkg/Bhyve/BhyveX64.dsc   |   
24 +-
 OvmfPkg/Bhyve/BhyveX64.fdf   |   
14 -
 OvmfPkg/CloudHv/CloudHvX64.dsc   |
1 -
 OvmfPkg/CloudHv/CloudHvX64.fdf   |
6 -
 OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c  

[edk2-devel] [PATCH 1/3] MdePkg: remove

[Laszlo Ersek]

Nothing in edk2 (or edk2-platforms, at this point) references
"LegacyBiosMpTable.h", or the names it introduces (EFI_LEGACY_MP_TABLE_*
and FEATUREBYTE2_5). Remove the header.

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1754
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h | 288 
 1 file changed, 288 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h 
b/MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h
deleted file mode 100644
index fa57f1ca10ce..
--- a/MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h
+++ /dev/null
@@ -1,288 +0,0 @@
-/** @file
-  Defives data structures per MultiProcessor Specification Ver 1.4.
-
-  The MultiProcessor Specification defines an enhancement to the standard
-  to which PC manufacturers design DOS-compatible systems.
-
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _LEGACY_BIOS_MPTABLE_H_
-#define _LEGACY_BIOS_MPTABLE_H_
-
-#define EFI_LEGACY_MP_TABLE_REV_1_4  0x04
-
-//
-// Define MP table structures. All are packed.
-//
-#pragma pack(1)
-
-#define EFI_LEGACY_MP_TABLE_FLOATING_POINTER_SIGNATURE  SIGNATURE_32 ('_', 
'M', 'P', '_')
-typedef struct {
-  UINT32Reserved1  : 6;
-  UINT32MutipleClk : 1;
-  UINT32Imcr   : 1;
-  UINT32Reserved2  : 24;
-} FEATUREBYTE2_5;
-
-typedef struct {
-  UINT32Signature;
-  UINT32PhysicalAddress;
-  UINT8 Length;
-  UINT8 SpecRev;
-  UINT8 Checksum;
-  UINT8 FeatureByte1;
-  FEATUREBYTE2_5FeatureByte2_5;
-} EFI_LEGACY_MP_TABLE_FLOATING_POINTER;
-
-#define EFI_LEGACY_MP_TABLE_HEADER_SIGNATURE  SIGNATURE_32 ('P', 'C', 'M', 'P')
-typedef struct {
-  UINT32Signature;
-  UINT16BaseTableLength;
-  UINT8 SpecRev;
-  UINT8 Checksum;
-  CHAR8 OemId[8];
-  CHAR8 OemProductId[12];
-  UINT32OemTablePointer;
-  UINT16OemTableSize;
-  UINT16EntryCount;
-  UINT32LocalApicAddress;
-  UINT16ExtendedTableLength;
-  UINT8 ExtendedChecksum;
-  UINT8 Reserved;
-} EFI_LEGACY_MP_TABLE_HEADER;
-
-typedef struct {
-  UINT8EntryType;
-} EFI_LEGACY_MP_TABLE_ENTRY_TYPE;
-
-//
-// Entry Type 0: Processor.
-//
-#define EFI_LEGACY_MP_TABLE_ENTRY_TYPE_PROCESSOR  0x00
-typedef struct {
-  UINT8Enabled  : 1;
-  UINT8Bsp  : 1;
-  UINT8Reserved : 6;
-} EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR_FLAGS;
-
-typedef struct {
-  UINT32Stepping : 4;
-  UINT32Model: 4;
-  UINT32Family   : 4;
-  UINT32Reserved : 20;
-} EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR_SIGNATURE;
-
-typedef struct {
-  UINT32Fpu   : 1;
-  UINT32Reserved1 : 6;
-  UINT32Mce   : 1;
-  UINT32Cx8   : 1;
-  UINT32Apic  : 1;
-  UINT32Reserved2 : 22;
-} EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR_FEATURES;
-
-typedef struct {
-  UINT8EntryType;
-  UINT8Id;
-  UINT8Ver;
-  EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR_FLAGSFlags;
-  EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR_SIGNATURESignature;
-  EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR_FEATURES Features;
-  UINT32   Reserved1;
-  UINT32   Reserved2;
-} EFI_LEGACY_MP_TABLE_ENTRY_PROCESSOR;
-
-//
-// Entry Type 1: Bus.
-//
-#define EFI_LEGACY_MP_TABLE_ENTRY_TYPE_BUS  0x01
-typedef struct {
-  UINT8EntryType;
-  UINT8Id;
-  CHAR8TypeString[6];
-} EFI_LEGACY_MP_TABLE_ENTRY_BUS;
-
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_CBUS"CBUS  " // Corollary CBus
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_CBUSII  "CBUSII" // Corollary 
CBUS II
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_EISA"EISA  " // Extended ISA
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_FUTURE  "FUTURE" // IEEE FutureBus
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_INTERN  "INTERN" // Internal bus
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_ISA "ISA   " // Industry 
Standard Architecture
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_MBI "MBI   " // Multibus I
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_MBII"MBII  " // Multibus II
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_MCA "MCA   " // Micro Channel 
Architecture
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_MPI "MPI   " // MPI
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_MPSA"MPSA  " // MPSA
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_NUBUS   "NUBUS " // Apple 
Macintosh NuBus
-#define EFI_LEGACY_MP_TABLE_ENTRY_BUS_STRING_PCI "PCI   " // Peripheral 
Component Interconnect
-#define EFI_LEGACY_MP_TABLE_ENT

[edk2-devel] [PATCH 3/3] MdePkg: remove

[Laszlo Ersek]

The MPS table is legacy from the traditional BIOS era. According to the
file-top comment in the header, it was only included in UEFI (and so in
edk2) for Itanium's sake (and Itanium is also gone from edk2).

Remove the header, and the MPS table GUID definition. There are no
references left in edk2 or edk2-platforms.

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1754
Signed-off-by: Laszlo Ersek 
---
 MdePkg/MdePkg.dec |  3 --
 MdePkg/Include/Guid/Mps.h | 29 
 2 files changed, 32 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index ac54338089e8..bac96ffd9896 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -388,9 +388,6 @@ [Guids]
   ## Include/Guid/SmBios.h
   gEfiSmbiosTableGuid= { 0xEB9D2D31, 0x2D88, 0x11D3, { 0x9A, 0x16, 
0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
 
-  ## Include/Guid/Mps.h
-  gEfiMpsTableGuid   = { 0xEB9D2D2F, 0x2D88, 0x11D3, { 0x9A, 0x16, 
0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
-
   ## Include/Protocol/AuthenticationInfo.h
   gEfiAuthenticationChapLocalGuid = { 0xC280C73E, 0x15CA, 0x11DA, { 0xB0, 
0xCA, 0x00, 0x10, 0x83, 0xFF, 0xCA, 0x4D }}
 
diff --git a/MdePkg/Include/Guid/Mps.h b/MdePkg/Include/Guid/Mps.h
deleted file mode 100644
index 0edcdbf2b9e8..
--- a/MdePkg/Include/Guid/Mps.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/** @file
-  GUIDs used for MPS entries in the UEFI 2.0 system table
-  ACPI is the primary means of exporting MPS information to the OS. MPS only 
was
-  included to support Itanium-based platform power on. So don't use it if you 
don't have too.
-
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-  SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  GUIDs defined in UEFI 2.0 spec.
-
-**/
-
-#ifndef __MPS_GUID_H__
-#define __MPS_GUID_H__
-
-#define EFI_MPS_TABLE_GUID \
-  { \
-0xeb9d2d2f, 0x2d88, 0x11d3, {0x9a, 0x16, 0x0, 0x90, 0x27, 0x3f, 0xc1, 0x4d 
} \
-  }
-
-//
-// GUID name defined in spec.
-//
-#define MPS_TABLE_GUID  EFI_MPS_TABLE_GUID
-
-extern EFI_GUID  gEfiMpsTableGuid;
-
-#endif


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

[edk2-devel] [PATCH 0/3] remove and , including refs

[Laszlo Ersek]

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1754

Remove two old headers that play no role in modern UEFI.

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

Laszlo Ersek (3):
  MdePkg: remove 
  ShellPkg/UefiShellDebug1CommandsLib: remove gEfiMpsTableGuid ref from
DMEM
  MdePkg: remove 

 MdePkg/Include/Guid/Mps.h  |  
29 --
 MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h| 
288 
 MdePkg/MdePkg.dec  |   
3 -
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |   
9 -
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf |   
1 -
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni |   
1 -
 6 files changed, 331 deletions(-)
 delete mode 100644 MdePkg/Include/Guid/Mps.h
 delete mode 100644 MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h


base-commit: bb18fb80abb9d35d01be5d693086a9ed4b9d65b5


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

[edk2-devel] [PATCH 2/3] ShellPkg/UefiShellDebug1CommandsLib: remove gEfiMpsTableGuid ref from DMEM

[Laszlo Ersek]

We're removing . First, remove the
gEfiMpsTableGuid system config table reference from the UEFI Shell's DMEM
debug command.

Cc: Zhichao Gao 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1754
Signed-off-by: Laszlo Ersek 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni | 1 
-
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf | 1 
-
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 9 
-
 3 files changed, 11 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
index 4041f0cd483e..155efc1a82f1 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
@@ -112,7 +112,6 @@
   "SAL System Table
  %016LX\r\n"
   "ACPI Table  
  %016LX\r\n"
   "ACPI 2.0 Table  
  %016LX\r\n"
-  "MPS Table   
  %016LX\r\n"
   "SMBIOS Table
  %016LX\r\n"
   "DTB Table   
  %016LX\r\n"
   "Memory Attribute Table  
  %016LX\r\n"
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
index 3741dac5d94c..2074cb7d96da 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
@@ -127,7 +127,6 @@ [Guids]
   gEfiGlobalVariableGuid  ## SOMETIMES_CONSUMES ## GUID
   gEfiSmbiosTableGuid ## SOMETIMES_CONSUMES ## SystemTable
   gEfiSmbios3TableGuid## SOMETIMES_CONSUMES ## SystemTable
-  gEfiMpsTableGuid## SOMETIMES_CONSUMES ## SystemTable
   gEfiAcpi10TableGuid ## SOMETIMES_CONSUMES ## SystemTable
   gEfiAcpi20TableGuid ## SOMETIMES_CONSUMES ## SystemTable
   gShellDebug1HiiGuid ## SOMETIMES_CONSUMES ## HII
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
index a609971f345e..39a59c195512 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -113,7 +112,6 @@ ShellCommandRunDmem (
   UINT64Acpi20TableAddress;
   UINT64SalTableAddress;
   UINT64SmbiosTableAddress;
-  UINT64MpsTableAddress;
   UINT64DtbTableAddress;
   UINT64MemoryAttributesTableAddress;
   UINT64RtPropertiesTableAddress;
@@ -190,7 +188,6 @@ ShellCommandRunDmem (
   AcpiTableAddress   = 0;
   SalTableAddress= 0;
   SmbiosTableAddress = 0;
-  MpsTableAddress= 0;
   DtbTableAddress= 0;
   MemoryAttributesTableAddress   = 0;
   RtPropertiesTableAddress   = 0;
@@ -224,11 +221,6 @@ ShellCommandRunDmem (
   continue;
 }
 
-if (CompareGuid (>ConfigurationTable[TableWalker].VendorGuid, 
)) {
-  MpsTableAddress = 
(UINT64)(UINTN)gST->ConfigurationTable[TableWalker].VendorTable;
-  continue;
-}
-
 if (CompareGuid (>ConfigurationTable[TableWalker].VendorGuid, 
)) {
   MemoryAttributesTableAddress = 
(UINT64)(UINTN)gST->ConfigurationTable[TableWalker].VendorTable;
   continue;
@@ -292,7 +284,6 @@ ShellCommandRunDmem (
 SalTableAddress,
 AcpiTableAddress,
 Acpi20TableAddress,
-MpsTableAddress,
 SmbiosTableAddress,
 DtbTableAddress,
 MemoryAttributesTableAddress,



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

[edk2-devel] [edk2-platforms PATCH 2/2] SimicsOpenBoardPkg: remove reference

[Laszlo Ersek]

For removing "MdePkg/Include/Guid/Mps.h" from edk2, first remove the
edk2-platforms references to that header file.

I can't build-test this change. As far as I can tell, building the
BoardX58Ich10 platform with "build_bios.py" should build the change;
however, that platform fails to build without an FSP blob.

I think there's a fair chance that this patch should work nonetheless;
 introduces EFI_MPS_TABLE_GUID, MPS_TABLE_GUID, and
gEfiMpsTableGuid, and edk2-platforms doesn't contain those strings.

Cc: Nate DeSimone 
Cc: Sai Chaganty 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1754
Signed-off-by: Laszlo Ersek 
---
 Platform/Intel/SimicsOpenBoardPkg/Library/BoardBdsHookLib/BoardBdsHook.h | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/Platform/Intel/SimicsOpenBoardPkg/Library/BoardBdsHookLib/BoardBdsHook.h 
b/Platform/Intel/SimicsOpenBoardPkg/Library/BoardBdsHookLib/BoardBdsHook.h
index 566b6a48c65d..62c6dfe9b52d 100644
--- a/Platform/Intel/SimicsOpenBoardPkg/Library/BoardBdsHookLib/BoardBdsHook.h
+++ b/Platform/Intel/SimicsOpenBoardPkg/Library/BoardBdsHookLib/BoardBdsHook.h
@@ -46,7 +46,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


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

[edk2-devel] [edk2-platforms PATCH 1/2] WhitleyOpenBoardPkg: remove references

[Laszlo Ersek]

For removing "MdePkg/Include/IndustryStandard/LegacyBiosMpTable.h" from
edk2, first remove the edk2-platforms references to that header file.

I can't build-test this change. As far as I can tell, building the
CooperCityRvp and WilsonCityRvp platforms with "build_bios.py" should
build these changes; however, both platforms fail to build without FSP
blobs.

I think there's a fair chance that this patch should work nonetheless;
 introduces names prefixed with EFI_LEGACY_MP_TABLE_,
and edk2-platforms doesn't contain that string. (The one exception is
FEATUREBYTE2_5, which is also absent from edk2-platforms.)

Cc: Sai Chaganty 
Cc: Nate DeSimone 
Cc: Chasel Chiu 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1754
Signed-off-by: Laszlo Ersek 
---
 
Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.h
 | 1 -
 
Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/PlatformDeviceDataSRP10nm.c
   | 1 -
 2 files changed, 2 deletions(-)

diff --git 
a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.h
 
b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.h
index 32c16ff9110a..d8c209a57f75 100644
--- 
a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.h
+++ 
b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.h
@@ -27,7 +27,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #endif  //_SYSTEM_BOARD_INFO_DXE_H_
diff --git 
a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/PlatformDeviceDataSRP10nm.c
 
b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/PlatformDeviceDataSRP10nm.c
index ed9f80734cd7..b69ae1736bb8 100644
--- 
a/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/PlatformDeviceDataSRP10nm.c
+++ 
b/Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/PlatformDeviceDataSRP10nm.c
@@ -8,7 +8,6 @@
 
 #include 
 #include 
-#include 
 
 #ifndef V_INTEL_VID
 #define V_INTEL_VID   0x8086



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

[edk2-devel] [edk2-platforms PATCH 0/2] remove and refs

[Laszlo Ersek]

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1754

Remove references to two old headers that play no role in modern UEFI.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Sai Chaganty 

Laszlo Ersek (2):
  WhitleyOpenBoardPkg: remove  references
  SimicsOpenBoardPkg: remove  reference

 Platform/Intel/SimicsOpenBoardPkg/Library/BoardBdsHookLib/BoardBdsHook.h   
   | 1 -
 
Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/Common/Dxe/SystemBoardInfoDxe/SystemBoardInfoDxe.h
 | 1 -
 
Platform/Intel/WhitleyOpenBoardPkg/Uba/UbaMain/StaticSkuDataDxe/PlatformDeviceDataSRP10nm.c
   | 1 -
 3 files changed, 3 deletions(-)


base-commit: 3c2f11d19e02a71c87ada8513bcbb0f0c504eebc


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

[edk2-devel] remove and , including references

[Laszlo Ersek]

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1754

I'm sending this as a common anchor message for

  [edk2-platforms PATCH 0/2] remove  and  refs
 [PATCH 0/3] remove  and , 
including refs

Thanks,
Laszlo



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

Re: [edk2-devel] [PATCH v2 24/30] OvmfPkg/LoongArchVirt: Add platform boot manager library

[Laszlo Ersek]

On 11/6/23 04:30, Chao Li wrote:
> This library is provides boot mananger interfaces, and it is referenced
> from ArmVirtPkg.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Signed-off-by: Chao Li 
> Co-authored-by: Xianglai Li 
> Co-authored-by: Bibo Mao 
> ---
>  .../PlatformBootManagerLib/PlatformBm.c   | 829 ++
>  .../PlatformBootManagerLib/PlatformBm.h   | 112 +++
>  .../PlatformBootManagerLib.inf|  73 ++
>  .../PlatformBootManagerLib/QemuKernel.c   |  81 ++
>  4 files changed, 1095 insertions(+)
>  create mode 100644 
> OvmfPkg/LoongArchVirt/Library/PlatformBootManagerLib/PlatformBm.c
>  create mode 100644 
> OvmfPkg/LoongArchVirt/Library/PlatformBootManagerLib/PlatformBm.h
>  create mode 100644 
> OvmfPkg/LoongArchVirt/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>  create mode 100644 
> OvmfPkg/LoongArchVirt/Library/PlatformBootManagerLib/QemuKernel.c

I wish it were "referenced"; it's not referenced but *copied*.

Why is the library in ArmVirtPkg not good enough? What are the
differences? Etc.

I'm not even asking about the specifics here, but trying to show you how
you should please *present* this platform enablement for review.

Laszlo



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

Re: [edk2-devel] [PATCH v2 23/30] OvmfPkg/LoongArchVirt: Add PeiServiceTablePointerLib

[Laszlo Ersek]

On 11/6/23 04:30, Chao Li wrote:
> Use a register to save PeiServiceTable pointer. This Library provides
> PeiServiceTable pointer saveing and retrieval serivces.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Signed-off-by: Chao Li 
> Co-authored-by: Xianglai Li 
> Co-authored-by: Bibo Mao 
> ---
>  .../PeiServicesTablePointer.c | 75 +++
>  .../PeiServicesTablePointerLib.inf| 31 
>  2 files changed, 106 insertions(+)
>  create mode 100644 
> OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointer.c
>  create mode 100644 
> OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf

Why is this under OvmfPkg?

Laszlo

> 
> diff --git 
> a/OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointer.c
>  
> b/OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointer.c
> new file mode 100644
> index 00..dcbcb50131
> --- /dev/null
> +++ 
> b/OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointer.c
> @@ -0,0 +1,75 @@
> +/** @file
> +  PEI Services Table Pointer Library.
> +
> +  Copyright (c) 2023 Loongson Technology Corporation Limited. All rights 
> reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Caches a pointer PEI Services Table.
> +
> +  Caches the pointer to the PEI Services Table specified by 
> PeiServicesTablePointer
> +  in a platform specific manner.
> +
> +  If PeiServicesTablePointer is NULL, then ASSERT ().
> +
> +  @paramPeiServicesTablePointer   The address of PeiServices pointer.
> +**/
> +VOID
> +EFIAPI
> +SetPeiServicesTablePointer (
> +  IN CONST EFI_PEI_SERVICES  **PeiServicesTablePointer
> +  )
> +{
> +  CsrWrite (LOONGARCH_CSR_KS0, (UINTN)PeiServicesTablePointer);
> +}
> +
> +/**
> +  Retrieves the cached value of the PEI Services Table pointer.
> +
> +  Returns the cached value of the PEI Services Table pointer in a CPU 
> specific manner
> +  as specified in the CPU binding section of the Platform Initialization 
> Pre-EFI
> +  Initialization Core Interface Specification.
> +
> +  If the cached PEI Services Table pointer is NULL, then ASSERT ().
> +
> +  @return  The pointer to PeiServices.
> +**/
> +CONST EFI_PEI_SERVICES **
> +EFIAPI
> +GetPeiServicesTablePointer (
> +  VOID
> +  )
> +{
> +  return (CONST EFI_PEI_SERVICES **)(CsrRead (LOONGARCH_CSR_KS0));
> +}
> +
> +/**
> +Perform CPU specific actions required to migrate the PEI Services Table
> +pointer from temporary RAM to permanent RAM.
> +
> +For IA32 CPUs, the PEI Services Table pointer is stored in the 4 bytes
> +immediately preceding the Interrupt Descriptor Table (IDT) in memory.
> +For X64 CPUs, the PEI Services Table pointer is stored in the 8 bytes
> +immediately preceding the Interrupt Descriptor Table (IDT) in memory.
> +For Itanium and ARM CPUs, a the PEI Services Table Pointer is stored in
> +a dedicated CPU register.  This means that there is no memory storage
> +associated with storing the PEI Services Table pointer, so no additional
> +migration actions are required for Itanium or ARM CPUs.
> +**/
> +VOID
> +EFIAPI
> +MigratePeiServicesTablePointer (
> +  VOID
> +  )
> +{
> +  return;
> +}
> diff --git 
> a/OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf
>  
> b/OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf
> new file mode 100644
> index 00..274cb2f781
> --- /dev/null
> +++ 
> b/OvmfPkg/LoongArchVirt/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf
> @@ -0,0 +1,31 @@
> +## @file
> +#  PEI Services Table Pointer Library.
> +#
> +#  Copyright (c) 2023 Loongson Technology Corporation Limited. All rights 
> reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = PeiServicesTablePointerLib
> +  FILE_GUID  = 098B0DB0-AD01-8886-D409-90CBC7E89154
> +  MODULE_TYPE= PEIM
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = PeiServicesTablePointerLib|PEIM PEI_CORE 
> SEC
> +
> +#
> +#  VALID_ARCHITECTURES   = LOONGARCH64
> +#
> +
> +[Sources]
> +  PeiServicesTablePointer.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +
> +[Pcd]



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

Re: [edk2-devel] [PATCH v2 20/30] OvmfPkg/LoongArchVirt: Add serial port library

[Laszlo Ersek]

On 11/7/23 11:12, Chao Li wrote:
> Hi Gerd,
> 
> These two libraries is not only copy code, the way of obtain the serial
> base address is different from ARM, and the early serial port output
> also different from ARM, so these two libraries are LoongArch specific.

I think we're going to have to go through the design with "baby steps".

The commit message of the patch is empty.

Please don't expect reviewers to "reverse engineer" the design from the
code. That's hugely taxing. It's hard enough to review code when we
precisey know in advance, from the commit message, what the code will
try to achieve.

You are saying that the way to obtain serial base address is different
from ARM, yet the GetSerialConsolePortAddress() function looks very
similar to the function that I *replaced* in recent commits eb83b5330961
("ArmVirtPkg: introduce FdtSerialPortAddressLib", 2023-10-26) and
f078a6fdd4d7 ("ArmVirtPkg/Fdt16550SerialPortHookLib: rebase to
FdtSerialPortAddressLib", 2023-10-26).

So there are two issues with your GetSerialConsolePortAddress() function
immediately, I would say:

- you say that it's different from ARM, but it seems to parse the DTB
identically (or mostly identically -- I'm speaking from memory),

- I factored out the subject DTB parsing logic in the above-noted
commits recently, so even if your GetSerialConsolePortAddress() function
is *supposed* to parse the DTB identically to ARM, then the way to
employ that logic is different; it should be reused, not duplicated.

Now that you have a running prototype (basically evidence that the port
to this new architecture can be done), can we go through the design of
each component (library, driver etc) one by one? Dumping the whole thing
on reviewers all at once, with little documentation, is not helpful. We
basically need to start with the specification of each of your modules.
See where the existing components in edk2 are not good enough or not
flexible enough, etc.

Laszlo



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

Re: [edk2-devel] [PATCH v4 11/14] UefiCpuPkg: Use Attribute From SMM MemoryAttributesTable if Nonzero

[Laszlo Ersek]

On 11/3/23 18:17, Taylor Beebe wrote:
> The function EnforceMemoryMapAttribute() in the SMM MAT logic will
> ensure that the CODE and DATA memory types have the desired attributes.

EnforceMemoryMapAttribute() leaves those descriptors alone where
Attribute is already nonzero ("PE image") [1].

For all other descriptors (i.e., where Attribute is zero), it:

- either sets Attribute to EFI_MEMORY_RO [2],

- or sets the EFI_MEMORY_XP *bit* in the Attribute [3] -- which is
identical to setting Attribute to EFI_MEMORY_XP altogether, given that
Attribute is zero to begin with. (So this |= operator looks like a
thinko in the function! But that's a separate topic.)

> The consumer of the SMM MAT

So this seems to imply that the SMM MAT is produced based on
EnforceMemoryMapAttribute(), and then SetMemMapAttributes(), modified in
this patch, is what consumes the SMM MAT. Is that right?

In other words, SetMemMapAttributes() relies on
EnforceMemoryMapAttribute(); is that your point?

> should only override the Attributes field
> in the MAT if it is nonzero.

I don't understand -- do you mean "override the Attributes field if it
is *zero*"? (Because, if it is nonzero, then it has been pre-populated
by EnforceMemoryMapAttribute(), and then we should *use* it, as the
subject line of the patch says.)

Further question: given that EnforceMemoryMapAttribute() exits with
*all* descriptors having a nonzero Attribute field, how is it possible
for SetMemMapAttributes() to see any descriptor with zero Attribute field?

I see two possibilities:

- something introduces a new descriptor between
EnforceMemoryMapAttribute() and SetMemMapAttributes()

- and/or, SetMemMapAttributes() doesn't actually check the entire
Attribute field for nullity, but only the EFI_MEMORY_ACCESS_MASK
bitfield of it. Cases [2] and [3] above ensure the
EFI_MEMORY_ACCESS_MASK bitmask is nonzero, but case [1] ("PE image")
allows for an Attribute field in the descriptor that is nonzero, but
whose EFI_MEMORY_ACCESS_MASK bitfield is zero.

> This also allows the UEFI and SMM MAT
> logic to use ImagePropertiesRecordLib instead of carrying two copies
> of the image properties record manipulation logic.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Taylor Beebe 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> index 6f498666157e..d302a9b0cbcf 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> @@ -1062,14 +1062,17 @@ SetMemMapAttributes (
>MemoryMap = MemoryMapStart;
>for (Index = 0; Index < MemoryMapEntryCount; Index++) {
>  DEBUG ((DEBUG_VERBOSE, "SetAttribute: Memory Entry - 0x%lx, 0x%x\n", 
> MemoryMap->PhysicalStart, MemoryMap->NumberOfPages));
> -if (MemoryMap->Type == EfiRuntimeServicesCode) {
> -  MemoryAttribute = EFI_MEMORY_RO;
> -} else {
> -  ASSERT ((MemoryMap->Type == EfiRuntimeServicesData) || 
> (MemoryMap->Type == EfiConventionalMemory));
> -  //
> -  // Set other type memory as NX.
> -  //
> -  MemoryAttribute = EFI_MEMORY_XP;
> +MemoryAttribute = MemoryMap->Attribute & EFI_MEMORY_ACCESS_MASK;

OK, so this line is what makes SetMemMapAttributes() rely on
EnforceMemoryMapAttribute().

What ensures the proper data flow, from EnforceMemoryMapAttribute() to
SetMemMapAttributes()?

> +if (MemoryAttribute == 0) {

So this seems to identify case [1] (... or an entirely newly added
descriptor)...

> +  if (MemoryMap->Type == EfiRuntimeServicesCode) {
> +MemoryAttribute = EFI_MEMORY_RO;
> +  } else {
> +ASSERT ((MemoryMap->Type == EfiRuntimeServicesData) || 
> (MemoryMap->Type == EfiConventionalMemory));
> +//
> +// Set other type memory as NX.
> +//
> +MemoryAttribute = EFI_MEMORY_XP;
> +  }
>  }
>  
>  //

Makes sense to me, but there are many open questions about the data
flow; I'd like the commit message to ELI5.

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH v2 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Set mSmmInterruptSspTables initial value

[Laszlo Ersek]

On 11/6/23 10:07, Sheng Wei wrote:
> Initial the value of mSmmInterruptSspTables to 0.
> 
> Signed-off-by: Sheng Wei 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Wu Jiaxin 
> Cc: Tan Dun 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> index c4f21e2155..6c53213b0b 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> @@ -20,7 +20,7 @@ UINT32mCetPl0Ssp;
>  UINT32mCetInterruptSsp;
>  UINT32mCetInterruptSspTable;
>  
> -UINTN  mSmmInterruptSspTables;
> +UINTN  mSmmInterruptSspTables = 0;
>  
>  /**
>Initialize IDT IST Field.

Please state your reason for this change in the commit message.

(Functionally, the patch is a no-op.)

Laszlo



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

Re: [edk2-devel] [PATCH v2 2/3] UefiCpuPkg/PiSmmCpuDxeSmm: Change CR4.CET bit only

[Laszlo Ersek]

On 11/6/23 10:07, Sheng Wei wrote:
> Do not use fixed CR4 value 0x668, change CR4.CET bit only.
> 
> Signed-off-by: Sheng Wei 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Wu Jiaxin 
> Cc: Tan Dun 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 9 ++---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm  | 3 ++-
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
> index 68332e2c3f..a087576a54 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
> @@ -260,7 +260,8 @@ CetInterruptDone:
>  bts ecx, 16 ; set WP
>  mov cr0, ecx
>  
> -mov eax, 0x668 | CR4_CET
> +mov eax, cr4
> +bts eax, CR4_CET_BIT
>  mov cr4, eax
>  
>  setssbsy
> @@ -292,8 +293,10 @@ CetDone:
>  xor edx, edx
>  wrmsr
>  
> -mov eax, 0x668
> -mov cr4, eax   ; disable CET
> +; clear CR4.CET bit
> +mov eax, cr4
> +btr eax, CR4_CET_BIT
> +mov cr4, eax
>  
>  mov ecx, MSR_IA32_PL0_SSP
>  pop eax
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
> index 007fbff640..7aed7c8dda 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
> @@ -287,7 +287,8 @@ CetInterruptDone:
>  bts ecx, 16 ; set WP
>  mov cr0, rcx
>  
> -mov eax, 0x668 | CR4_CET
> +mov rax, cr4
> +bts rax, CR4_CET_BIT
>  mov cr4, rax
>  
>  setssbsy

I didn't understand why the X64 code here didn't contain the "btr"
counterpart of "bts". Well the reason is that the "missing" btr is
actually introduced in the previous patch.

I find that confusing. I think that, once you have "Cet.inc", you should
separately replace CR4_CET with CR4_CET_BIT, both in "Cet.inc" and in
the three existent locations (two in the IA32 entry code and one in the
X64 entry code).

*Then* you could proceed to clearing CR4.CET in the subsequent patch,
using CR4_CET_BIT.

Laszlo



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

Re: [edk2-devel] [PATCH v2 1/3] UefiCpuPkg/PiSmmCpuDxeSmm: Clear CR4.CET before restoring MSR IA32_S_CET

[Laszlo Ersek]

On 11/6/23 10:07, Sheng Wei wrote:
> Clear CR4.CET bit before restoring MSR IA32_S_CET.
> Backup/restore MSR IA32_U_CET in SMI.

(1) As far as I understand, these are still two separate fixes. And I
think this patch has issues due to trying to fix both issues at the same
time. (I could be wrong of course, I'm not familiar with CET, but this
is my impression.) More details on this below.

(2) Each issue / fix (i.e., the one issue / fix per patch) should be
explained in detail, even if you think the issue that each patch fixes
is obvious.

> 
> Signed-off-by: Sheng Wei 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Wu Jiaxin 
> Cc: Tan Dun 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 53 ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm  | 69 
>  2 files changed, 98 insertions(+), 24 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
> index 19de5f614e..68332e2c3f 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
> @@ -16,18 +16,19 @@
>  %include "StuffRsbNasm.inc"
>  %include "Nasm.inc"
>  
> +%define MSR_IA32_U_CET 0x6A0
>  %define MSR_IA32_S_CET 0x6A2
> -%define   MSR_IA32_CET_SH_STK_EN 0x1
> -%define   MSR_IA32_CET_WR_SHSTK_EN   0x2
> -%define   MSR_IA32_CET_ENDBR_EN  0x4
> -%define   MSR_IA32_CET_LEG_IW_EN 0x8
> -%define   MSR_IA32_CET_NO_TRACK_EN   0x10
> -%define   MSR_IA32_CET_SUPPRESS_DIS  0x20
> -%define   MSR_IA32_CET_SUPPRESS  0x400
> -%define   MSR_IA32_CET_TRACKER   0x800
> +%define MSR_IA32_CET_SH_STK_EN 0x1
> +%define MSR_IA32_CET_WR_SHSTK_EN   0x2
> +%define MSR_IA32_CET_ENDBR_EN  0x4
> +%define MSR_IA32_CET_LEG_IW_EN 0x8
> +%define MSR_IA32_CET_NO_TRACK_EN   0x10
> +%define MSR_IA32_CET_SUPPRESS_DIS  0x20
> +%define MSR_IA32_CET_SUPPRESS  0x400
> +%define MSR_IA32_CET_TRACKER   0x800
>  %define MSR_IA32_PL0_SSP   0x6A4
>  
> -%define CR4_CET0x80
> +%define CR4_CET_BIT23
>  
>  %define MSR_IA32_MISC_ENABLE 0x1A0
>  %define MSR_EFER  0xc080

(3) These assembly language macros should have been introduced in an
include file (*.inc).

These "SmiEntry.nasm" files already %include "StuffRsbNasm.inc" and
"Nasm.inc", so placing the CET-related macros side-by-side with those
files, for example in a new file called "Cet.inc", would be the right
thing. It would eliminate the duplication between the IA32 and X64 nasm
files.

Please prepend a patch to the series that moves the existent macros to
"Cet.nasm", and then in this patch, add the new macros to "Cet.nasm" /
modify the old ones inside "Cet.nasm".


> @@ -214,11 +215,21 @@ ASM_PFX(mPatchCetSupported):
>  pushedx
>  pusheax
>  
> +mov ecx, MSR_IA32_U_CET
> +rdmsr
> +pushedx
> +pusheax
> +

So this is related to saving CET_U state; we're pushing the MSR contents
to the stack right after having saving CET_S state similarly.

>  mov ecx, MSR_IA32_PL0_SSP
>  rdmsr
>  pushedx
>  pusheax
>  
> +mov ecx, MSR_IA32_U_CET
> +xor eax, eax
> +xor edx, edx
> +wrmsr
> +
>  mov ecx, MSR_IA32_S_CET
>  mov eax, MSR_IA32_CET_SH_STK_EN
>  xor edx, edx

This seems to clear CET_U state. Why is that necessary?

The commit message only says "backup/restore"; it does not say "clear".

I assume your main goal is *clearing* CET_U state for the duration of
the SMI, and that's why you want to backup/restore (so that the clearing
does not destroy information). I guess.

(4) But this should be explained in the commit message.

> @@ -276,6 +287,11 @@ CetDone:
>  cmp al, 0
>  jz  CetDone2
>  
> +mov ecx, MSR_IA32_S_CET
> +xor eax, eax
> +xor edx, edx
> +wrmsr
> +
>  mov eax, 0x668
>  mov cr4, eax   ; disable CET
>  

(5) This logic then appears to belong to the *other* fix, namely nulling
(?) CET_S state before clearing CR4.CET.

> @@ -284,10 +300,15 @@ CetDone:
>  pop edx
>  wrmsr
>  
> -mov ecx, MSR_IA32_S_CET
> +mov ecx, MSR_IA32_U_CET
>  pop eax
>  pop edx
>  wrmsr
> +
> +mov ecx, MSR_IA32_S_CET
> +pop eax
> +pop edx
> +mov ebx, eax
>  CetDon

Re: [edk2-devel] [PATCH v4 4/4] StandaloneMmPkg/Core: Fix the failure to find uncompressed inner FV

[Laszlo Ersek]

On 11/6/23 08:52, Xu, Wei6 wrote:
> The MmCoreFfsFindMmDriver only checks for encapsulated compressed FVs.
> When an inner FV is uncompressed, StandaloneMmCore will miss the FV and
> all the MM drivers in the FV will not be dispatched.
> Add checks for uncompressed inner FV to fix this issue.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Ray Ni 
> Signed-off-by: Wei6 Xu 
> ---
>  StandaloneMmPkg/Core/FwVol.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index 4d2b63a448e7..07500cee41f3 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -79,6 +79,8 @@ MmCoreFfsFindMmDriver (
>UINTN   DepexSize;
>UINTN   Index;
>EFI_COMMON_SECTION_HEADER   *Section;
> +  VOID*SectionData;
> +  UINTN   SectionDataSize;
>UINT32  DstBufferSize;
>VOID*ScratchBuffer;
>UINT32  ScratchBufferSize;
> @@ -115,6 +117,26 @@ MmCoreFfsFindMmDriver (
>break;
>  }
>  
> +//
> +// Check uncompressed firmware volumes
> +//
> +Status = FfsFindSectionData (
> +   EFI_SECTION_FIRMWARE_VOLUME_IMAGE,
> +   FileHeader,
> +   ,
> +   
> +   );
> +if (!EFI_ERROR (Status)) {
> +  if (SectionDataSize > sizeof (EFI_FIRMWARE_VOLUME_HEADER)) {
> +InnerFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)SectionData;
> +MmCoreFfsFindMmDriver (InnerFvHeader, Depth + 1);
> +continue;
> +  }
> +}
> +
> +//
> +// Check compressed firmware volumes
> +//
>  Status = FfsFindSection (
> EFI_SECTION_GUID_DEFINED,
> FileHeader,

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v4 3/4] StandaloneMmPkg/Core: Fix issue that offset calculation might be wrong

[Laszlo Ersek]

On 11/6/23 08:52, Xu, Wei6 wrote:
> MmCoreFfsFindMmDriver() assumes FileHeader is EFI_FFS_FILE_HEADER.
> If FileHeader is an EFI_FFS_FILE_HEADER2, 'FileHeader + 1' will get a
> wrong section address. Use FfsFindSection to get the section directly,
> instead of 'FileHeader + 1' to avoid this issue.
> MmCoreFfsFindMmDriver() also assumes section is EFI_COMMON_SECTION_HEADER.
> If Section is EFI_COMMON_SECTION_HEADER2, 'Section + 1' will get a wrong
> wrong InnerFvHeader adress. Add section head detection and calculate the
> address accordingly.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Ray Ni 
> Signed-off-by: Wei6 Xu 
> ---
>  StandaloneMmPkg/Core/FwVol.c | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index c3054ef751ed..4d2b63a448e7 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -79,8 +79,6 @@ MmCoreFfsFindMmDriver (
>UINTN   DepexSize;
>UINTN   Index;
>EFI_COMMON_SECTION_HEADER   *Section;
> -  VOID*SectionData;
> -  UINTN   SectionDataSize;
>UINT32  DstBufferSize;
>VOID*ScratchBuffer;
>UINT32  ScratchBufferSize;
> @@ -117,23 +115,21 @@ MmCoreFfsFindMmDriver (
>break;
>  }
>  
> -Status = FfsFindSectionData (
> +Status = FfsFindSection (
> EFI_SECTION_GUID_DEFINED,
> FileHeader,
> -   ,
> -   
> +   
> );
>  if (EFI_ERROR (Status)) {
>break;
>  }
>  
> -Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
> -Status  = ExtractGuidedSectionGetInfo (
> -Section,
> -,
> -,
> -
> -);
> +Status = ExtractGuidedSectionGetInfo (
> +   Section,
> +   ,
> +   ,
> +   
> +   );
>  if (EFI_ERROR (Status)) {
>break;
>  }
> @@ -194,8 +190,13 @@ MmCoreFfsFindMmDriver (
>goto FreeDstBuffer;
>  }
>  
> -InnerFvHeader = (VOID *)(Section + 1);
> -Status= MmCoreFfsFindMmDriver (InnerFvHeader, Depth + 1);
> +if (IS_SECTION2 (Section)) {
> +  InnerFvHeader = (VOID *)((EFI_COMMON_SECTION_HEADER2 *)Section + 1);
> +} else {
> +  InnerFvHeader = (VOID *)(Section + 1);
> +}
> +
> +Status = MmCoreFfsFindMmDriver (InnerFvHeader, Depth + 1);
>  if (EFI_ERROR (Status)) {
>goto FreeDstBuffer;
>  }

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v4 2/4] StandaloneMmPkg/Core: Fix potential memory leak issue

[Laszlo Ersek]

On 11/6/23 08:52, Xu, Wei6 wrote:
> In MmCoreFfsFindMmDriver(),
> - ScratchBuffer is not freed in the error return path that DstBuffer page
> allocation fails. Free ScratchBuffer before return with error.
> - If the decoded buffer is identical to the data in InputSection,
> ExtractGuidedSectionDecode() will change the value of DstBuffer rather
> than changing the contents of the buffer that DstBuffer points at, in
> which case freeing DstBuffer is wrong. Introduce a local variable
> AllocatedDstBuffer for buffer free, free AllocatedDstBuffer immediately
> if it is not used.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Ray Ni 
> Signed-off-by: Wei6 Xu 
> ---
>  StandaloneMmPkg/Core/FwVol.c | 31 ++-
>  1 file changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index e1e20ffd14ac..c3054ef751ed 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -84,6 +84,7 @@ MmCoreFfsFindMmDriver (
>UINT32  DstBufferSize;
>VOID*ScratchBuffer;
>UINT32  ScratchBufferSize;
> +  VOID*AllocatedDstBuffer;
>VOID*DstBuffer;
>UINT16  SectionAttribute;
>UINT32  AuthenticationStatus;
> @@ -148,25 +149,35 @@ MmCoreFfsFindMmDriver (
>  //
>  // Allocate destination buffer, extra one page for adjustment
>  //
> -DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (DstBufferSize));
> -if (DstBuffer == NULL) {
> +AllocatedDstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (DstBufferSize));
> +if (AllocatedDstBuffer == NULL) {
> +  FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES (ScratchBufferSize));
>return EFI_OUT_OF_RESOURCES;
>  }
>  
>  //
>  // Call decompress function
>  //
> -Status = ExtractGuidedSectionDecode (
> -   Section,
> -   ,
> -   ScratchBuffer,
> -   
> -   );
> +DstBuffer = AllocatedDstBuffer;
> +Status= ExtractGuidedSectionDecode (
> +  Section,
> +  ,
> +  ScratchBuffer,
> +  
> +  );
>  FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES (ScratchBufferSize));
>  if (EFI_ERROR (Status)) {
>goto FreeDstBuffer;
>  }
>  
> +//
> +// Free allocated DstBuffer if it is not used
> +//
> +if (DstBuffer != AllocatedDstBuffer) {
> +  FreePages (AllocatedDstBuffer, EFI_SIZE_TO_PAGES (DstBufferSize));
> +  AllocatedDstBuffer = NULL;
> +}
> +
>  DEBUG ((
>DEBUG_INFO,
>"Processing compressed firmware volume (AuthenticationStatus == %x)\n",
> @@ -210,7 +221,9 @@ MmCoreFfsFindMmDriver (
>return EFI_SUCCESS;
>  
>  FreeDstBuffer:
> -  FreePages (DstBuffer, EFI_SIZE_TO_PAGES (DstBufferSize));
> +  if (AllocatedDstBuffer != NULL) {
> +FreePages (AllocatedDstBuffer, EFI_SIZE_TO_PAGES (DstBufferSize));
> +  }
>  
>return Status;
>  }

Right, if AllocatedDstBuffer is needed, then we free it only upon error;
otherwise, we free it early on, so that it's released upon both error
and success.

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v4 1/4] StandaloneMmPkg/Core: Limit FwVol encapsulation section recursion

[Laszlo Ersek]

On 11/6/23 08:52, Xu, Wei6 wrote:
> MmCoreFfsFindMmDriver() is called recursively for encapsulation sections.
> Currently this recursion is not limited. Introduce a new PCD
> (fixed-at-build, or patchable-in-module), and make MmCoreFfsFindMmDriver()
> track the section nesting depth against that PCD.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Ray Ni 
> Signed-off-by: Wei6 Xu 
> ---
>  StandaloneMmPkg/Core/Dispatcher.c |  5 -
>  StandaloneMmPkg/Core/FwVol.c  | 16 --
>  StandaloneMmPkg/Core/StandaloneMmCore.c   |  7 +-
>  StandaloneMmPkg/Core/StandaloneMmCore.h   | 26 +++
>  StandaloneMmPkg/Core/StandaloneMmCore.inf |  3 +++
>  StandaloneMmPkg/StandaloneMmPkg.dec   |  5 +
>  6 files changed, 49 insertions(+), 13 deletions(-)
> 
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c 
> b/StandaloneMmPkg/Core/Dispatcher.c
> index b1ccba15b060..7b4a3c4c552b 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -53,11 +53,6 @@ typedef struct {
>  // Function Prototypes
>  //
>  
> -EFI_STATUS
> -MmCoreFfsFindMmDriver (
> -  IN  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader
> -  );
> -
>  /**
>Insert InsertedDriverEntry onto the mScheduledQueue. To do this you
>must add any driver with a before dependency on InsertedDriverEntry first.

Whoa, so we actually had an (unused) declaration in "Dispatcher.c" as
well, which we missed in v3 altogether. I assume now that the
declaration is moved to the header file, the compiler reports the
conflict! In v3 this declaration actually got out of sync, IIUC. So the
declaration centralizaton has already paid off.

Reviewed-by: Laszlo Ersek 

Laszlo

> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index 1f6d7714ba97..e1e20ffd14ac 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -48,6 +48,9 @@ FvIsBeingProcessed (
>MM driver and return its PE32 image.
>  
>@param [in] FwVolHeader   Pointer to memory mapped FV
> +  @param [in] Depth Nesting depth of encapsulation sections. Callers
> +different from MmCoreFfsFindMmDriver() are
> +responsible for passing in a zero Depth.
>  
>@retval  EFI_SUCCESSSuccess.
>@retval  EFI_INVALID_PARAMETER  Invalid parameter.
> @@ -55,11 +58,15 @@ FvIsBeingProcessed (
>@retval  EFI_OUT_OF_RESOURCES   Out of resources.
>@retval  EFI_VOLUME_CORRUPTED   Firmware volume is corrupted.
>@retval  EFI_UNSUPPORTEDOperation not supported.
> +  @retval  EFI_ABORTEDRecursion aborted because Depth has been
> +  greater than or equal to
> +  PcdFwVolMmMaxEncapsulationDepth.
>  
>  **/
>  EFI_STATUS
>  MmCoreFfsFindMmDriver (
> -  IN  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader
> +  IN  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader,
> +  IN  UINT32  Depth
>)
>  {
>EFI_STATUS  Status;
> @@ -84,6 +91,11 @@ MmCoreFfsFindMmDriver (
>  
>DEBUG ((DEBUG_INFO, "MmCoreFfsFindMmDriver - 0x%x\n", FwVolHeader));
>  
> +  if (Depth >= PcdGet32 (PcdFwVolMmMaxEncapsulationDepth)) {
> +DEBUG ((DEBUG_ERROR, "%a: recursion aborted due to nesting depth\n", 
> __func__));
> +return EFI_ABORTED;
> +  }
> +
>if (FvHasBeenProcessed (FwVolHeader)) {
>  return EFI_SUCCESS;
>}
> @@ -172,7 +184,7 @@ MmCoreFfsFindMmDriver (
>  }
>  
>  InnerFvHeader = (VOID *)(Section + 1);
> -Status= MmCoreFfsFindMmDriver (InnerFvHeader);
> +Status= MmCoreFfsFindMmDriver (InnerFvHeader, Depth + 1);
>  if (EFI_ERROR (Status)) {
>goto FreeDstBuffer;
>  }
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
> b/StandaloneMmPkg/Core/StandaloneMmCore.c
> index d221f1d1115d..1074f309d718 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.c
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
> @@ -9,11 +9,6 @@
>  
>  #include "StandaloneMmCore.h"
>  
> -EFI_STATUS
> -MmCoreFfsFindMmDriver (
> -  IN  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader
> -  );
> -
>  EFI_STATUS
>  MmDispatcher (
>VOID
> @@ -643,7 +638,7 @@ StandaloneMmMain (
>//
>DEBUG ((DEBUG_INFO, "Mm Dispatch StandaloneBfvAddress - 0x%08x\n", 
> gMmCorePrivate->StandaloneBfvAddress));
>if (gMmCorePrivate->StandaloneBfvAddress != 0) {
> -MmCoreFfsFindMmDriver ((EFI_FIRMWARE_VOLUME_HEADER 
> *)(UINTN)gMmCorePrivate->StandaloneBfvAddress);
> +MmCoreFfsF

Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridgeDxe: Add readback after final Cfg-Write

[Laszlo Ersek]

On 11/6/23 07:55, Joe L wrote:
> (1) I'd like (a) the problem report, and the full reasoning by Ard and
> Michael to be captured in the commit message, and (b) *minimally* a hint
> at the possible reordering, and at the PCI spec-based workaround, to be
> placed in the code comment as well.
> 
> Laszlo, please forgive me if this is the wrong way to reply (I am new to
> the patch process on edk2, should I instead send a new [PATCH v2] with
> changes based on your feedback?)

Yes please, the updates for the patch (commit message and code) should
be incorporated into a v2 posting.

> 
> Including the problem report and reasoning in the commit/comment:
> 
> REF:https://edk2.groups.io/g/devel/topic/102310377#110456
> 
> 
> Problem Report:
> On AARCH64, there is no ordering guarantee between configuration
> space (ECAM) writes and memory space reads (MMIO). ARM AMBA CHI
> only guarantees ordering for reads and writes within a single address
> region,
> however, on some systems MMIO and ECAM may be split into separate
> address regions.
> A problem may arise when an ECAM write is issued a completion before a
> subsequent
> MMIO read is issued and receives a completion.
> For example, a typical PCI software flow is the following:
>     1. ECAM write to device command register to enable memory space
>     2. MMIO read from device memory space for which access was enabled
>         in step 1.
> There is no guarantee that step 2. will not begin before the completion
> of step 1.
> on systems where ECAM/MMIO are specified as separate address regions, even
> if both spaces have the memory attributes device-nGnRnE.
> 
> - Add a read after the final PCI Configuration space write
> in RootBridgeIoPciAccess.
> 
> - When configuration space is strongly ordered, this ensures
> that program execution cannot continue until the completion
> is received for the previous Cfg-Write, which may have side-effects.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Pedro Falcato 
> Cc: Michael Brown 
> Signed-off-by: Joe Lopez 
> ---
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index 157a0ada80..4bc774b574 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -1238,6 +1238,13 @@ RootBridgeIoPciAccess (
> }
> }
> 
> + //
> + // Perform readback after write to confirm completion was received for
> the last write
> +  // before subsequent memory operations can be issued.
> + //
> + if (!Read) {
> + PciSegmentRead8 (Address - InStride);
> + }
> +
> return EFI_SUCCESS;
> }

Thanks for addressing this point. (Apologies if meanwhile other comments
have been made in this thread; I've been "write-only" for a few days
now, due to a long queue of patch reviews. If I keep fetching new email,
just the "triaging" takes so much time that I can't progress with the
accrued patches.)


> 
>  
> 
> (2) This is a significant change; please file a new tianocore BZ about
> it. If we include it in the upcoming stable release, the BZ should be
> listed here, too:
> 
> Is a separate thread (other than this patch thread) needed to ensure
> that the BZ is created for this issue?

Please register an account at , and
file a bug there ("EDK2" product). Then link the new ticket into the
commit message. We usually add:

Ref: 

just above the Signed-off-by line.


> 
> (3) I seem to understand that the outcome of the discusson thus far is
> that reading back any config space register should be without side
> effects. (In turn, this should be documented in the comment and the
> commit message! But, my more important point here is:)
> 
> In the PCI Base Spec version 6.1 section 7.4 "Configuration Register
> Types" all configuration space registers are assigned one of the
> attributes (quoting Michael Brown in the previous thread)
> 
> If reads are not allowed to have side effects (e.g. read-clear
> registers) then this seems safe. The PCIe specification
> "Configuration Register Types" list comprises (in version 3.0, at
> least):
> 
> HwInit - read-only, no read side effects
> 
> RO - read-only, no read side effects
> 
> RW - read-write, no read side effects
> 
> RW1C - write 1 to clear bits, no read side effects
> 
> ROS - read-only, no read side effects
> 
> RWS - read-write, no read side effects
> 
> RW1CS - write 1 to clear bits, no read side effects
> 
> RsvdP - read-write, no read side effects
> 
> RsvdZ - read-write, no read side effects
> 
> So, unless newer versions of the PCIe specification have allowed for
> 

Re: [edk2-devel] [PATCH v4] UefiCpuPkg/PiSmmCpuDxeSmm: Fix CP Exception when CET enable

[Laszlo Ersek]

On 11/7/23 02:24, Wu, Jiaxin wrote:
> Root cause:
> 1. Before DisableReadonlyPageWriteProtect() is called, the return
> address (#1) is pushed in shadow stack.
> 2. CET is disabled.
> 3. DisableReadonlyPageWriteProtect() returns to #1.
> 4. Page table is modified.
> 5. EnableReadonlyPageWriteProtect() is called, but the return
> address (#2) is not pushed in shadow stack.
> 6. CET is enabled.
> 7. EnableReadonlyPageWriteProtect() returns to #2.
> #CP exception happens because the actual return address (#2)
> doesn't match the return address stored in shadow stack (#1).
> 
> Analysis:
> Shadow stack will stop update after CET disable (DisableCet() in
> DisableReadOnlyPageWriteProtect), but normal smi stack will be
> continue updated with the function called and return
> (DisableReadOnlyPageWriteProtect & EnableReadOnlyPageWriteProtect),
> thus leading stack mismatch after CET re-enabled (EnableCet() in
> EnableReadOnlyPageWriteProtect).
> 
> According SDM Vol 3, 6.15-Control Protection Exception:
> Normal smi stack and shadow stack must be matched when CET enable,
> otherwise CP Exception will happen, which is caused by a near RET
> instruction.
> 
> CET is disabled in DisableCet(), while can be enabled in
> EnableCet(). This way won't cause the problem because they are
> implemented in a way that return address of DisableCet() is
> poped out from shadow stack (Incsspq performs a pop to increases
> the shadow stack) and EnableCet() doesn't use "RET" but "JMP" to
> return to caller. So calling EnableCet() and DisableCet() doesn't
> have the same issue as calling DisableReadonlyPageWriteProtect()
> and EnableReadonlyPageWriteProtect().
> 
> With above root cause & analysis, define below 2 macros instead of
> functions for WP & CET operation:
> WRITE_UNPROTECT_RO_PAGES (Wp, Cet)
> WRITE_PROTECT_RO_PAGES (Wp, Cet)
> Because DisableCet() & EnableCet() must be in the same function
> to avoid shadow stack and normal SMI stack mismatch.
> 
> Note: WRITE_UNPROTECT_RO_PAGES () must be called pair with
> WRITE_PROTECT_RO_PAGES () in same function.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Cc: Gerd Hoffmann 
> Cc: Rahul Kumar 
> Cc: Laszlo Ersek 
> Signed-off-by: Jiaxin Wu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 59 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 73 
> +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  7 ++-
>  3 files changed, 81 insertions(+), 58 deletions(-)

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v1] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

[Laszlo Ersek]

On 11/7/23 19:40, Laszlo Ersek wrote:
> On 11/7/23 03:43, Wu, Jiaxin wrote:
>> Processor extended information is filled when
>> CPU_V2_EXTENDED_TOPOLOGY is set in parameter ProcessorNumber
>> from GetProcessorInfo() (See commit: 1fadd18d).
>>
>> This filed value is retrieved from CPUID leaf 1FH, which is
>> a preferred superset to leaf 0BH.
>>
>> Since Intel recommends first use the CPUID leaf 1FH instead of
>> leaf 0BH, this patch change to use the processor extended
>> information, which can reflect the value from CPUID leaf 1FH.
>>
>> Cc: Eric Dong 
>> Cc: Ray Ni 
>> Cc: Rahul Kumar 
>> Cc: Gerd Hoffmann 
>> Cc: Star Zeng 
>> Signed-off-by: Jiaxin Wu 
>> ---
>>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 10 ++
>>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  6 +++---
>>  2 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c 
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
>> index 391b64e9f2..c0485b0519 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
>> @@ -169,10 +169,20 @@ SmmAddProcessor (
>>  >ProcessorInfo[Index].Location.Package,
>>  >ProcessorInfo[Index].Location.Core,
>>  >ProcessorInfo[Index].Location.Thread
>>  );
>>  
>> +  GetProcessorLocation2ByApicId (
>> +(UINT32)ProcessorId,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Package,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Die,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Tile,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Module,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Core,
>> +
>> >ProcessorInfo[Index].ExtendedInformation.Location2.Thread
>> +);
>> +
>>*ProcessorNumber = Index;
>>gSmmCpuPrivate->Operation[Index] = SmmCpuAdd;
>>return EFI_SUCCESS;
>>  }
>>}
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>> index 25d058c5b9..c61562c867 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>> @@ -177,11 +177,11 @@ IsPackageFirstThread (
>>IN UINTN  CpuIndex
>>)
>>  {
>>UINT32  PackageIndex;
>>  
>> -  PackageIndex =  gSmmCpuPrivate->ProcessorInfo[CpuIndex].Location.Package;
>> +  PackageIndex =  
>> gSmmCpuPrivate->ProcessorInfo[CpuIndex].ExtendedInformation.Location2.Package;
>>  
>>ASSERT (mPackageFirstThreadIndex != NULL);
>>  
>>//
>>// Set the value of mPackageFirstThreadIndex[PackageIndex].
>> @@ -1834,12 +1834,12 @@ InitPackageFirstThreadIndexInfo (
>>  
>>//
>>// Count the number of package, set to max PackageId + 1
>>//
>>for (Index = 0; Index < mNumberOfCpus; Index++) {
>> -if (PackageId < gSmmCpuPrivate->ProcessorInfo[Index].Location.Package) {
>> -  PackageId = gSmmCpuPrivate->ProcessorInfo[Index].Location.Package;
>> +if (PackageId < 
>> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package) {
>> +  PackageId = 
>> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package;
>>  }
>>}
>>  
>>PackageCount = PackageId + 1;
>>  
> 
> The patch looks OK to me, but:
> 
> - I would like to test it with CPU hotplug (later, likely under v2), and
> 
> - I think this should be two patches.
> 
> First, the SmmAddProcessor() function should be extended just to
> complete commit 1fadd18d. (BTW I highly appreciate the reference to
> commit 1fadd18d; otherwise I couldn't find where the *coldplugged* CPUs'
> locations were retrieved!)
> 
> Then the Package calculations should be updated separately -- mostly
> because I would appreciate a concrete description in that separate
> commit message why the difference matters. Clearly you have a use case
> where the v1 and v2 package numbers differ, and recording that in the
> commit history would be great.

Side note, just for completeness: the x2apic lib instance performs the
v2 feature detection correctly since Gerd's commit 170d4ce8e90a
("UefiCpuPkg/BaseXApicX2ApicLib: fix CPUID_V2_EXTENDED_TOPOLOGY
detection", 2023-10-25). Furthermore, OVMF uses the x2apic lib instance
since commit decb365b0016 ("OvmfPkg: select LocalApicLib instance with
x2apic support", 2015-11-30). Therefore, this patch looks fine for OVMF.

However, for platforms that use the old xapic lib instance, there could
be problems, as the v2 feature detection in *that* instance is not fixed
-- it does not check EBX.

Laszlo



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

Re: [edk2-devel] [PATCH v1] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

[Laszlo Ersek]

On 11/7/23 03:43, Wu, Jiaxin wrote:
> Processor extended information is filled when
> CPU_V2_EXTENDED_TOPOLOGY is set in parameter ProcessorNumber
> from GetProcessorInfo() (See commit: 1fadd18d).
> 
> This filed value is retrieved from CPUID leaf 1FH, which is
> a preferred superset to leaf 0BH.
> 
> Since Intel recommends first use the CPUID leaf 1FH instead of
> leaf 0BH, this patch change to use the processor extended
> information, which can reflect the value from CPUID leaf 1FH.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Star Zeng 
> Signed-off-by: Jiaxin Wu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 10 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  6 +++---
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> index 391b64e9f2..c0485b0519 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c
> @@ -169,10 +169,20 @@ SmmAddProcessor (
>  >ProcessorInfo[Index].Location.Package,
>  >ProcessorInfo[Index].Location.Core,
>  >ProcessorInfo[Index].Location.Thread
>  );
>  
> +  GetProcessorLocation2ByApicId (
> +(UINT32)ProcessorId,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Package,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Die,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Tile,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Module,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Core,
> +
> >ProcessorInfo[Index].ExtendedInformation.Location2.Thread
> +);
> +
>*ProcessorNumber = Index;
>gSmmCpuPrivate->Operation[Index] = SmmCpuAdd;
>return EFI_SUCCESS;
>  }
>}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 25d058c5b9..c61562c867 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -177,11 +177,11 @@ IsPackageFirstThread (
>IN UINTN  CpuIndex
>)
>  {
>UINT32  PackageIndex;
>  
> -  PackageIndex =  gSmmCpuPrivate->ProcessorInfo[CpuIndex].Location.Package;
> +  PackageIndex =  
> gSmmCpuPrivate->ProcessorInfo[CpuIndex].ExtendedInformation.Location2.Package;
>  
>ASSERT (mPackageFirstThreadIndex != NULL);
>  
>//
>// Set the value of mPackageFirstThreadIndex[PackageIndex].
> @@ -1834,12 +1834,12 @@ InitPackageFirstThreadIndexInfo (
>  
>//
>// Count the number of package, set to max PackageId + 1
>//
>for (Index = 0; Index < mNumberOfCpus; Index++) {
> -if (PackageId < gSmmCpuPrivate->ProcessorInfo[Index].Location.Package) {
> -  PackageId = gSmmCpuPrivate->ProcessorInfo[Index].Location.Package;
> +if (PackageId < 
> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package) {
> +  PackageId = 
> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package;
>  }
>}
>  
>PackageCount = PackageId + 1;
>  

The patch looks OK to me, but:

- I would like to test it with CPU hotplug (later, likely under v2), and

- I think this should be two patches.

First, the SmmAddProcessor() function should be extended just to
complete commit 1fadd18d. (BTW I highly appreciate the reference to
commit 1fadd18d; otherwise I couldn't find where the *coldplugged* CPUs'
locations were retrieved!)

Then the Package calculations should be updated separately -- mostly
because I would appreciate a concrete description in that separate
commit message why the difference matters. Clearly you have a use case
where the v1 and v2 package numbers differ, and recording that in the
commit history would be great.

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH v8 0/5] Cache Management Operations Support For RISC-V

[Laszlo Ersek]

On 11/7/23 08:15, Sunil V L wrote:
> On Mon, Nov 06, 2023 at 08:23:51AM +0530, Dhaval wrote:
>> Implementing code to support Cache Management Operations (CMO) defined by
>> RISC-V CMO instructions.https://github.com/riscv/riscv-CMOs
>> This is a re-write of original series v5.
>> The patchset contains 5 patches- created based on V5 feedback.
>> 1. Restructuring of existing code and move instruction declarations into 
>> BaseLib
>> 2. Renaming existing functions to denote type of instruction used to maanage 
>> cache.
>>This is useful for further patches where more cache management 
>> instructions are added.
>> 3. Add the new cache maintenance operations to BaseLib, including the
>>   new assembly instruction encodings.
>> 4. Update BaseCacheMaintenanceLib (utilizing the new BaseLib primitives)
>> 5. Add platform level PCD to allow overriding of RISC-V features.
>>
>> Code Link: https://github.com/tianocore/edk2/pull/5002
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jiewen Yao 
>> Cc: Jordan Justen 
>> Cc: Gerd Hoffmann 
>> Cc: Sunil V L 
>> Cc: Andrei Warkentin 
>> Cc: Laszlo Ersek 
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Cc: Zhiguang Liu 
>> Cc: Daniel Schaefer 
>>
>> Dhaval (5):
>>   MdePkg: Move RISC-V Cache Management Declarations Into BaseLib
>>   MdePkg: Rename Cache Management Function To Clarify Fence Based Op
>>   MdePkg: Implement RISC-V Cache Management Operations
>>   MdePkg: Utilize Cache Management Operations Implementation For RISC-V
>>   OvmfPkg/RiscVVirt: Override for RV CPU Features
> 
> If nobody objects,  I will merge this tomorrow  with or without ack from
> MdePkg maintainers. The changes are related to RISC-V only anyway.

I think you'll have to ask Mike or Liming to do the merge, given that
we're now in soft feature freeze. I do agree though that the series's
review completed in time for the merge; v8 picked up tags given previously.

Laszlo



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

Re: [edk2-devel] [PATCH v2 2/2] FatPkg/EnhancedFatDxe: Fix OVERFLOW_BEFORE_WIDEN Coverity issue

[Laszlo Ersek]

On 11/7/23 07:28, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The function FatInitializeDiskCache evaluates an expression
> 
> FAT_DATACACHE_GROUP_COUNT << DiskCache[CacheData].PageAlignment
> 
> and assigns it to DataCacheSize which is of type UINTN.
> 
> As per Coverity report,
> FAT_DATACACHE_GROUP_COUNT << DiskCache[CacheData].PageAlignment is a
> potentially overflowing expression with type "int" (32 bits, signed)
> evaluated using 32-bit arithmetic, and then used in a context that
> expects an expression of type "UINTN" (64 bits, unsigned).
> 
> To avoid overflow, cast "FAT_DATACACHE_GROUP_COUNT" to type "UINTN".
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4249
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  FatPkg/EnhancedFatDxe/DiskCache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/FatPkg/EnhancedFatDxe/DiskCache.c 
> b/FatPkg/EnhancedFatDxe/DiskCache.c
> index d1a34a6a646f..d56e338586d8 100644
> --- a/FatPkg/EnhancedFatDxe/DiskCache.c
> +++ b/FatPkg/EnhancedFatDxe/DiskCache.c
> @@ -477,7 +477,7 @@ FatInitializeDiskCache (
>DiskCache[CacheFat].BaseAddress   = Volume->FatPos;
>DiskCache[CacheFat].LimitAddress  = Volume->FatPos + Volume->FatSize;
>FatCacheSize  = FatCacheGroupCount << 
> DiskCache[CacheFat].PageAlignment;
> -  DataCacheSize = FAT_DATACACHE_GROUP_COUNT << 
> DiskCache[CacheData].PageAlignment;
> +  DataCacheSize = (UINTN)FAT_DATACACHE_GROUP_COUNT << 
> DiskCache[CacheData].PageAlignment;
>//
>// Allocate the Fat Cache buffer
>//

I don't understand Coverity here. This is the larger context (extract):

  //
  // Configure the parameters of disk cache
  //
  if (Volume->FatType == Fat12) {
DiskCache[CacheData].PageAlignment = FAT_DATACACHE_PAGE_MIN_ALIGNMENT;
  } else {
DiskCache[CacheData].PageAlignment = FAT_DATACACHE_PAGE_MAX_ALIGNMENT;
  }

  DataCacheSize = FAT_DATACACHE_GROUP_COUNT << 
DiskCache[CacheData].PageAlignment;

In practice, one of two things can happen: either

  DataCacheSize = 64 << 13;

or

  DataCacheSize = 64 << 16;

The larger value is 2 MB, it happily fits in an INT32.

I don't mind the patch, but the commit message, and a new code comment as well, 
should state that we're only casting to shut up Coverity.

If the shift count "DiskCache[CacheData].PageAlignment" were *indeed* 
unbounded, then we'd have much more serious problems. First, we could shift by 
64 bits or more, which is undefined even if we cast to UINT64 at first. Second, 
even assuming "DataCacheSize" can be calculated correctly, just below it we have

  CacheBuffer = AllocateZeroPool (FatCacheSize + DataCacheSize);

where the *addition* can nicely overflow regardless.

The patch is OK but it requires a comment, and a commit message update.

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH v2 1/2] FatPkg/EnhancedFatDxe: Fix SIGN_EXTENSION Coverity issues

[Laszlo Ersek]

On 11/7/23 07:28, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The functions FatGetDirEntInfo and FatOpenDirEnt contains the code
> statements
> 
>   Cluster= (Entry->FileClusterHigh << 16) | 
> Entry->FileCluster;
>   and
>   OFile->FileCluster = ((DirEnt->Entry.FileClusterHigh) << 16) | 
> (DirEnt->Entry.FileCluster);
> 
> respectively. As per Coverity report, in both these statements, there is
> an "Operand1" with type "UINT16" (16 bits, unsigned) which is promoted in
> "(Operand1 << 16) | Operand2" to type "int" (32 bits, signed), then sign-
> extended to type "unsigned long long" (64 bits, unsigned). If the result
> of "(Operand1 << 16) | Operand2" is greater than 0x7FFF, the upper
> bits of the result will all be 1.
> 
> So to avoid sign-extension, typecast the Operand1 and then the inter-
> -mediate result after << 16 operation with UINTN. Note - UINTN is the
> data type of the variable on the LHS of the assignment.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4249
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  FatPkg/EnhancedFatDxe/DirectoryManage.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/FatPkg/EnhancedFatDxe/DirectoryManage.c 
> b/FatPkg/EnhancedFatDxe/DirectoryManage.c
> index 723fc35f38db..a21b7973cd21 100644
> --- a/FatPkg/EnhancedFatDxe/DirectoryManage.c
> +++ b/FatPkg/EnhancedFatDxe/DirectoryManage.c
> @@ -474,7 +474,7 @@ FatGetDirEntInfo (
>  Info   = Buffer;
>  Info->Size = ResultSize;
>  if ((Entry->Attributes & FAT_ATTRIBUTE_DIRECTORY) != 0) {
> -  Cluster= (Entry->FileClusterHigh << 16) | 
> Entry->FileCluster;
> +  Cluster= (UINTN)((UINTN)(Entry->FileClusterHigh) << 16) | 
> Entry->FileCluster;
>Info->PhysicalSize = FatPhysicalDirSize (Volume, Cluster);
>Info->FileSize = Info->PhysicalSize;
>  } else {
> @@ -1167,7 +1167,7 @@ FatOpenDirEnt (
>//
>Volume = Parent->Volume;
>OFile->FullPathLen = Parent->FullPathLen + 1 + StrLen 
> (DirEnt->FileString);
> -  OFile->FileCluster = ((DirEnt->Entry.FileClusterHigh) << 16) | 
> (DirEnt->Entry.FileCluster);
> +  OFile->FileCluster = (UINTN)((UINTN)(DirEnt->Entry.FileClusterHigh) << 
> 16) | (DirEnt->Entry.FileCluster);
>InsertTailList (>ChildHead, >ChildLink);
>  } else {
>//

The gist of the Coverity report is that the FileClusterHigh field has
type UINT16 and is promoted to "int", and then shifting that "int" left
by 16 bits may cause the result not to fit, and because "int" is signed,
this is undefined behavior by C standard.

The simplest fix is this (both cases):

  ((UINT32)FileClusterHigh << 16) | FileCluster

I.e., just cast FileClusterHigh to UINT32.

This way:

- the left-shift is safe,

- the FileCluster operand, which is also UINT16 and is also promoted to
"int" (INT32), is converted to UINT32, for the bit-or,

- the result of the bit-or has type UINT32, which, if UINTN is UINT64,
is converted to UINT64 for the sake of the assignment, without change of
value. The LHS in both cases is indeed UINTN.

Laszlo



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

Re: [edk2-devel] [PATCH v2 5/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix UNUSED_VALUE Coverity issues

[Laszlo Ersek]

On 11/7/23 07:19, Ranbir Singh wrote:
> The return value after calls to functions
> gBS->UninstallMultipleProtocolInterfaces, StartPciDevicesOnBridge,
> PciPciDeviceInfoCollector, BarExisted, PciRootBridgeIo->Pci.Write,
> gPciHotPlugInit->InitializeRootHpc and PciRootBridgeP2CProcess is
> stored in Status, but it is not made of any use and later Status
> gets overridden.
> 
> Remove the return value storage in Status or add Status check as
> seems appropriate at a particular point.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> 
> Cc: Ray Ni 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 68 
> +++-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 42 
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |  8 +++
>  3 files changed, 72 insertions(+), 46 deletions(-)

First of all, please split up this patch. It's hard to review it like
this, with unrelated pieces of logic lumped together.

> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> index 3de80d98370e..9b0587c94d05 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> @@ -544,12 +544,12 @@ DeRegisterPciDevice (
>EFI_OPEN_PROTOCOL_TEST_PROTOCOL
>);
>if (!EFI_ERROR (Status)) {
> -Status = gBS->UninstallMultipleProtocolInterfaces (
> -Handle,
> -,
> ->LoadFile2,
> -NULL
> -);
> +gBS->UninstallMultipleProtocolInterfaces (
> +   Handle,
> +   ,
> +   >LoadFile2,
> +   NULL
> +   );
>}
>  
>//

OK

> @@ -678,19 +678,21 @@ StartPciDevicesOnBridge (
> ChildHandleBuffer
> );
>  
> -PciIoDevice->PciIo.Attributes (
> - &(PciIoDevice->PciIo),
> - EfiPciIoAttributeOperationSupported,
> - 0,
> - 
> - );
> -Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
> -PciIoDevice->PciIo.Attributes (
> - &(PciIoDevice->PciIo),
> - EfiPciIoAttributeOperationEnable,
> - Supports,
> - NULL
> - );
> +if (!EFI_ERROR (Status)) {
> +  PciIoDevice->PciIo.Attributes (
> +   &(PciIoDevice->PciIo),
> +   EfiPciIoAttributeOperationSupported,
> +   0,
> +   
> +   );
> +  Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
> +  PciIoDevice->PciIo.Attributes (
> +   &(PciIoDevice->PciIo),
> +   EfiPciIoAttributeOperationEnable,
> +   Supports,
> +   NULL
> +   );
> +}
>  
>  return Status;
>} else {

OK

> @@ -726,19 +728,21 @@ StartPciDevicesOnBridge (
> ChildHandleBuffer
> );
>  
> -PciIoDevice->PciIo.Attributes (
> - &(PciIoDevice->PciIo),
> - EfiPciIoAttributeOperationSupported,
> - 0,
> - 
> - );
> -Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
> -PciIoDevice->PciIo.Attributes (
> - &(PciIoDevice->PciIo),
> - EfiPciIoAttributeOperationEnable,
> - Supports,
> - NULL
> - );
> +if (!EFI_ERROR (Status)) {
> +  PciIoDevice->PciIo.Attributes (
> +   &(PciIoDevice->PciIo),
> +   EfiPciIoAttributeOperationSupported,
> +   0,
> +   
> +   );
> +  Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
> +  PciIoDevice->PciIo.Attributes (
> +   &(PciIoDevice->PciIo),
> +   EfiPciIoAttributeOperationEnable,
> +   Supports,
> +   NULL
> +   );
> +}
>}
>  
>CurrentLink = CurrentLink->ForwardLink;

I don't really like this; the original code is inconsistent. In the
first branch, StartPciDevicesOnBridge() failure is fatal, here it isn't. :/

Anyway, I agree we can at least restrict 

Re: [edk2-devel] [PATCH v2 4/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix NULL_RETURNS Coverity issue

[Laszlo Ersek]

On 11/7/23 07:19, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The function StartPciDevices has a check
> 
> ASSERT (RootBridge != NULL);
> 
> but this comes into play only in DEBUG mode. In Release mode, there
> is no handling if the RootBridge value is NULL and the code proceeds
> to unconditionally dereference "RootBridge" which will lead to CRASH.
> 
> Hence, for safety add NULL pointer checks always and return
> EFI_NOT_READY if RootBridge value is NULL which is one of the return
> values as mentioned in the function description header.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> index 581e9075ad41..3de80d98370e 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> @@ -772,7 +772,10 @@ StartPciDevices (
>LIST_ENTRY *CurrentLink;
>  
>RootBridge = GetRootBridgeByHandle (Controller);
> -  ASSERT (RootBridge != NULL);
> +  if (RootBridge == NULL) {
> +return EFI_NOT_READY;
> +  }
> +
>ThisHostBridge = RootBridge->PciRootBridgeIo->ParentHandle;
>  
>CurrentLink = mPciDevicePool.ForwardLink;

I don't think this is a good fix.

There is one call site, namely in PciBusDriverBindingStart(). That call
site does not check the return value. (Of course /s)

I think that this ASSERT() can indeed never fail. Therefore I suggest
CpuDeadLoop() instead.

If you insist that CpuDeadLoop() is "too risky" here, then the patch is
acceptable, but then the StartPciDevices() call site in
PciBusDriverBindingStart() must check the error properly: we must not
install "gEfiPciEnumerationCompleteProtocolGuid", and the function must
propagate the error outwards.

Laszlo



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

Re: [edk2-devel] [PATCH v2 3/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix ARRAY_VS_SINGLETON Coverity issues

[Laszlo Ersek]

On 11/7/23 07:19, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The function PciHostBridgeResourceAllocator is not making use of the
> generic approach as is used in one of the other function namely -
> DumpResourceMap. As a result, the following warnings can be seen as
> reported by Coverity e.g.
> 
> (30) Event address_of:Taking address with "" yields a
>  singleton pointer.
> (31) Event callee_ptr_arith:  Passing "" to function
>  "FindResourceNode" which uses it as an array. This might corrupt
>  or misinterpret adjacent memory locations.
> 
> Hence, adopt the generic approach to fix the issues at relevant points.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 37 
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> index 84fc0161a19c..71767d3793d4 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> @@ -485,6 +485,8 @@ PciHostBridgeResourceAllocator (
>UINT64 Mem64ResStatus;
>UINT64 PMem64ResStatus;
>UINT32 MaxOptionRomSize;
> +  PCI_RESOURCE_NODE  **ChildResources;
> +  UINTN  ChildResourceCount;
>PCI_RESOURCE_NODE  *IoBridge;
>PCI_RESOURCE_NODE  *Mem32Bridge;
>PCI_RESOURCE_NODE  *PMem32Bridge;
> @@ -895,16 +897,39 @@ PciHostBridgeResourceAllocator (
>  // Create the entire system resource map from the information collected 
> by
>  // enumerator. Several resource tree was created
>  //
> -FindResourceNode (RootBridgeDev, , );
> -FindResourceNode (RootBridgeDev, , );
> -FindResourceNode (RootBridgeDev, , );
> -FindResourceNode (RootBridgeDev, , );
> -FindResourceNode (RootBridgeDev, , );
> -
> +ChildResourceCount = FindResourceNode (RootBridgeDev, , NULL);
> +ChildResources = AllocatePool (sizeof (PCI_RESOURCE_NODE *) * 
> ChildResourceCount);
> +ASSERT (ChildResources != NULL);
> +FindResourceNode (RootBridgeDev, , [0]);
> +IoBridge = ChildResources[0];
>  ASSERT (IoBridge != NULL);
> +
> +ChildResourceCount = FindResourceNode (RootBridgeDev, , NULL);
> +ChildResources = AllocatePool (sizeof (PCI_RESOURCE_NODE *) * 
> ChildResourceCount);
> +ASSERT (ChildResources != NULL);
> +FindResourceNode (RootBridgeDev, , [0]);
> +Mem32Bridge = ChildResources[0];
>  ASSERT (Mem32Bridge  != NULL);
> +
> +ChildResourceCount = FindResourceNode (RootBridgeDev, , NULL);
> +ChildResources = AllocatePool (sizeof (PCI_RESOURCE_NODE *) * 
> ChildResourceCount);
> +ASSERT (ChildResources != NULL);
> +FindResourceNode (RootBridgeDev, , [0]);
> +PMem32Bridge = ChildResources[0];
>  ASSERT (PMem32Bridge != NULL);
> +
> +ChildResourceCount = FindResourceNode (RootBridgeDev, , NULL);
> +ChildResources = AllocatePool (sizeof (PCI_RESOURCE_NODE *) * 
> ChildResourceCount);
> +ASSERT (ChildResources != NULL);
> +FindResourceNode (RootBridgeDev, , [0]);
> +Mem64Bridge = ChildResources[0];
>  ASSERT (Mem64Bridge  != NULL);
> +
> +ChildResourceCount = FindResourceNode (RootBridgeDev, , NULL);
> +ChildResources = AllocatePool (sizeof (PCI_RESOURCE_NODE *) * 
> ChildResourceCount);
> +ASSERT (ChildResources != NULL);
> +FindResourceNode (RootBridgeDev, , [0]);
> +PMem64Bridge = ChildResources[0];
>  ASSERT (PMem64Bridge != NULL);
>  
>  //

Sorry, but this is terrible.

* First of all, Coverity is *wrong*. The C spec clearly states that, for
the purposes of pointer arithmetic, a singleton object behaves
identically to the first element of an array.

So, immediately, the idea arises that we should just use

  PCI_RESOURCE_NODE *IoBridgeArray[1];

  FindResourceNode (RootBridgeDev, , IoBridgeArray)

to shut up Coverity.

* Unfortunately, I expect that would only create a different warning: a
warning about potentially overflowing this single-element array. Which
is in fact a deeper problem in FindResourceNode() -- it happily
overwrites an array that is too small.

* Finally, this generic approach is both ugly (lots of code
duplication!), and worse, it allocates memory without proper error
checking (ASSERT() is not error checking), and then it leaks
ChildResources *multiple times*!

I suggest the following, for solving all of these issues:

- create a function called FindFirstResourceNode(). It should have the
same function prototype as FindResourceNode(), except the last parameter
should be mandatory, not OPTIONAL.

Re: [edk2-devel] [PATCH v2 2/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix MISSING_BREAK Coverity issues

[Laszlo Ersek]

On 11/7/23 07:19, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The function UpdatePciInfo has switch-case code in which there are fall
> through from case 32: to case 64:. While this is seeemingly intentional,
> it is not evident to any general code reader why there is no break; in
> between. Adding
> 
> // No break; here as this is an intentional fallthrough.
> 
> as comment in between makes it explicit. Incidentally, the comment
> satisfies Coverity as well.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> index 6594b8eae83f..eda97285ee18 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> @@ -1428,6 +1428,9 @@ UpdatePciInfo (
>switch (Ptr->AddrSpaceGranularity) {
>  case 32:
>PciIoDevice->PciBar[BarIndex].BarType = PciBarTypeMem32;
> +  //
> +  // No break; here as this is an intentional fall through.
> +  //
>  case 64:
>PciIoDevice->PciBar[BarIndex].BarTypeFixed = TRUE;
>break;
> @@ -1440,6 +1443,9 @@ UpdatePciInfo (
>switch (Ptr->AddrSpaceGranularity) {
>  case 32:
>PciIoDevice->PciBar[BarIndex].BarType = PciBarTypePMem32;
> +  //
> +  // No break; here as this is an intentional fall through.
> +  //
>  case 64:
>PciIoDevice->PciBar[BarIndex].BarTypeFixed = TRUE;
>    break;

Agree, but the semicolon's placement is awkward. I propose

  No break here, as this is an intentional fall through.

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH v2 1/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix DEADCODE Coverity issue

[Laszlo Ersek]

On 11/7/23 07:19, Ranbir Singh wrote:
> From: Ranbir Singh 
> 
> The function PciHotPlugRequestNotify has two if blocks towards the end
> of function both containing return. Due to the parameter checks ensured
> at the beginning of the function, one of the two if blocks is bound to
> come in execution flow. Hence, the return EFI_SUCCESS; at line 2112 is
> redundant/deadcode.

Agree with the analysis.

> 
> To fix it, either of line 2109 or 2112 can be deleted.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
> index 3f8c6e6da7dc..5b71e152f3ea 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
> @@ -2106,7 +2106,6 @@ PciHotPlugRequestNotify (
>  //
>  // End for
>  //
> -return EFI_SUCCESS;
>}
>  
>return EFI_SUCCESS;

Disagree with the fix.

Given the checks on "Operation" at the top of the function, the
condition (near the end of the function)

  if (Operation == EfiPciHotplugRequestRemove) {

will always evaluate to TRUE. (Operation can be only Add or Remove, and
if it is Add, then we don't reach this location.)

Therefore, we should remove this condition, and *unnest* the dependent
logic.

As a result of *that*, you'll have

  return EFI_SUCCESS;
  return EFI_SUCCESS;

at the end of the function, and *then* you should remove either one of them.

Thanks
Laszlo



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