Date   

Re: [PATCH] .azurepipelines: Enable CI for WhiskeylakeOpenBoard in Edk2platforms

Ni, Ray
 

Acked-by: Ray Ni <ray.ni@intel.com>

Sean, Bret, Mike, Liming, any comments?

-----Original Message-----
From: Tan, Dun <dun.tan@intel.com>
Sent: Friday, October 8, 2021 5:45 PM
To: devel@edk2.groups.io; Tan, Dun <dun.tan@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Ni, Ray <ray.ni@intel.com>
Subject: RE: [edk2-devel] [PATCH] .azurepipelines: Enable CI for WhiskeylakeOpenBoard in Edk2platforms

Hi all,
Can you please help to review this patch? Thanks a lot.

Thanks,
Dun
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of duntan
Sent: Wednesday, September 29, 2021 2:43 PM
To: devel@edk2.groups.io; Tan, Dun <dun.tan@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Ni, Ray <ray.ni@intel.com>
Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for WhiskeylakeOpenBoard in Edk2platforms

Hi all,

Since I don't have the administrator access of Tiano edk2 CI, I can't create a new pipeline based on my .yml file to test my script.
So I have to copy the content in edk2-platforms.yml to Windows-VS2019.yml and change file in the included path in .yml file to
trigger the PR CI and verify whether the edk2platforms CI test can pass. Here is the PR link and the azure pipeline CI link.
https://github.com/tianocore/edk2/pull/2027
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=30289&view=results

Thanks,
Dun
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of duntan
Sent: Wednesday, September 29, 2021 2:38 PM
To: devel@edk2.groups.io
Cc: Sean Brogan <sean.brogan@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Ni, Ray <ray.ni@intel.com>
Subject: [edk2-devel] [PATCH] .azurepipelines: Enable CI for WhiskeylakeOpenBoard in Edk2platforms

The edk2-platforms.yml contains the necessary github repo that will be checked out, the platform name to build and the folders
in edk2 which will trigger the CI. The edk2platforms-run-steps.yml contains the main steps to build WhiskeylakeOpenBoard.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>

Signed-off-by: Dun Tan <dun.tan@intel.com>
---
.azurepipelines/edk2-platforms.yml | 71
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.azurepipelines/edk2platforms-run-steps.yml | 72
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 143 insertions(+)

diff --git a/.azurepipelines/edk2-platforms.yml b/.azurepipelines/edk2-platforms.yml
new file mode 100644
index 0000000000..5d47e213ad
--- /dev/null
+++ b/.azurepipelines/edk2-platforms.yml
@@ -0,0 +1,71 @@
+## @file
+# Azure Pipeline build file for WhiskeylakeOpenBoard in Edk2platforms
+on windows and ubuntu # # Copyright (c) 2021, Intel Corporation. All
+rights reserved.<BR> # SPDX-License-Identifier: BSD-2-Clause-Patent ##
+trigger:
+ - master
+ - stable/*
+pr:
+ branches:
+ include:
+ - master
+ - stable/*
+ paths:
+ include:
+ - BaseTools
+ - CryptoPkg
+ - FatPkg
+ - IntelFsp2WrapperPkg
+ - MdeModulePkg
+ - MdePkg
+ - NetworkPkg
+ - PcAtChipsetPkg
+ - SecurityPkg
+ - ShellPkg
+ - UefiCpuPkg
+
+resources:
+ repositories:
+ - repository: edk2-platforms
+ type: github
+ endpoint: tianocore
+ name: tianocore/edk2-platforms
+ - repository: edk2-non-osi
+ type: github
+ endpoint: tianocore
+ name: tianocore/edk2-non-osi
+ - repository: FSP
+ type: github
+ endpoint: tianocore
+ name: intel/FSP
+
+jobs:
+ - job: Edk2Platforms_CI_Windows
+ pool:
+ vmImage: 'windows-latest'
+ strategy:
+ matrix:
+ WhiskeylakeOpenBoard_WhiskeylakeURvp:
+ Board.Name: "WhiskeylakeURvp"
+ WhiskeylakeOpenBoard_UpXtreme:
+ Board.Name: "UpXtreme"
+ steps:
+ - template: edk2platforms-run-steps.yml
+ parameters:
+ board_name: $(Board.Name)
+ pool_name: 'windows-latest'
+
+ - job: Edk2Platforms_CI_Linux
+ pool:
+ vmImage: 'ubuntu-latest'
+ strategy:
+ matrix:
+ WhiskeylakeOpenBoard_WhiskeylakeURvp:
+ Board.Name: "WhiskeylakeURvp"
+ steps:
+ - template: edk2platforms-run-steps.yml
+ parameters:
+ board_name: $(Board.Name)
+ pool_name: 'ubuntu-latest'
diff --git a/.azurepipelines/edk2platforms-run-steps.yml b/.azurepipelines/edk2platforms-run-steps.yml
new file mode 100644
index 0000000000..04b5d40fd8
--- /dev/null
+++ b/.azurepipelines/edk2platforms-run-steps.yml
@@ -0,0 +1,72 @@
+## @file
+# File templates/edk2platforms-run-steps.yml
+#
+# template file containing the steps to build # # Copyright (c) 2021,
+Intel Corporation. All rights reserved.<BR> # SPDX-License-Identifier:
+BSD-2-Clause-Patent ##
+parameters:
+- name: board_name
+ type: string
+ default: ''
+- name: pool_name
+ type: string
+ default: ''
+
+steps:
+- checkout: self
+ submodules: true
+- checkout: edk2-non-osi
+- checkout: FSP
+- checkout: edk2-platforms
+
+- task: UsePythonVersion@0
+ inputs:
+ versionSpec: "3.8.x"
+ architecture: "x64"
+
+- ${{ if contains(parameters.pool_name, 'ubuntu') }}:
+ - bash: |
+ sudo apt-get update
+ sudo apt-get install gcc g++ make uuid-dev nasm iasl
+ displayName: Update apt and Install required tools
+ - script: |
+ source edksetup.sh
+ echo "##vso[task.setvariable variable=PATH;]$PATH"
+ displayName: Set env Path
+ workingDirectory: edk2/
+
+- ${{ if contains(parameters.pool_name, 'windows') }}:
+ - powershell: |
+ choco install iasl -y --version=2017.11.10
+ echo "##vso[task.setvariable variable=IASL_PREFIX;]C:\tools\ASL\"
+ choco install nasm -y
+ echo "##vso[task.setvariable variable=NASM_PREFIX;]C:\Program Files\NASM\"
+ displayName: Windows EDK II Prerequisites
+
+# Build WhiskeylakeOpenBoard in edk2platforms
+- script: python build_bios.py --platform ${{ parameters.board_name}}
+ displayName: Build platform ${{ parameters.board_name}}
+ workingDirectory: edk2-platforms/Platform/Intel
+
+# Copy the build logs to the artifact staging directory
+- task: CopyFiles@2
+ displayName: "Copy build logs"
+ inputs:
+ targetFolder: "$(Build.ArtifactStagingDirectory)"
+ SourceFolder:
+ contents: |
+ Build.log
+ BuildReport.log
+ flattenFolders: true
+ condition: succeededOrFailed()
+
+# Publish build artifacts to Azure Artifacts/TFS or a file share
+- task: PublishBuildArtifacts@1
+ continueOnError: true
+ displayName: "Publish build logs"
+ inputs:
+ pathtoPublish: "$(Build.ArtifactStagingDirectory)"
+ artifactName: "Build Logs $(System.JobName)"
+ condition: succeededOrFailed()
--
2.31.1.windows.1










Re: [PATCH V2 12/28] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VE exception #ve

Min Xu
 

On October 26, 2021 2:12 PM, Gerd Hoffmann wrote:
On Tue, Oct 26, 2021 at 05:06:21AM +0000, Xu, Min M wrote:
On October 12, 2021 6:27 PM, Gerd Hoffmann wrote:
+ if (ExceptionType == VE_EXCEPTION) {
+ EFI_STATUS Status;
+ //
+ // #VE needs to be handled immediately upon enabling exception
handling
+ // and therefore can't use the RegisterCpuInterruptHandler()
interface.

Can please you explain in more detail why this is the case?
VE Exception may happen before a component registers exception.

So it has to be implemented inside the exception lib.
Well, no, you can also change the code to avoid triggering an exception.

Adding a new lib for the exception means the lib must be added into each
and every *.dsc file (either the tdx impl or the null variant), not only in the
tianocore core itself but also all projects depending on tianocore.

So IMHO it is worth checking out how much effort it would be to avoid early
(before component registration) exceptions.

Which early exception do actually happen?
RegisterCpuInterfaceHandler() is not supported in SEC/PEI phase. But there are still some scenarios in SEC/PEI which will trigger #VE.
CPUID is the sample. See below call chain in CpuMpPei.
InitializeCpuMpWorker --> CollectBitsDataFromPpi --> MpInitLibGetProcessorInfo --> GetProcessorLocationByApicId()

Actually #VE handler follows the same way as #VC handler (by SEV). See discussions in below link.
https://edk2.groups.io/g/devel/topic/73201885

Thanks
Min


[PATCH] IntelFsp2Pkg/SplitFspBin.py: adopt FSP 2.3 specification.

Chiu, Chasel
 

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

FSP 2.3 has updated FSP_INFO_HEADER to support ExtendedImageRevision
and SplitFspBin.py needs to support it.

Also updated script to display integer value basing on length.

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
---
IntelFsp2Pkg/Tools/SplitFspBin.py | 66 +++++++++++++++++++++++++++++++++++=
+++++++++----------------------
1 file changed, 44 insertions(+), 22 deletions(-)

diff --git a/IntelFsp2Pkg/Tools/SplitFspBin.py b/IntelFsp2Pkg/Tools/SplitFs=
pBin.py
index 24272e82af..20e329a76e 100644
--- a/IntelFsp2Pkg/Tools/SplitFspBin.py
+++ b/IntelFsp2Pkg/Tools/SplitFspBin.py
@@ -1,6 +1,6 @@
## @ FspTool.py=0D
#=0D
-# Copyright (c) 2015 - 2020, Intel Corporation. All rights reserved.<BR>=0D
+# Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.<BR>=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
##=0D
@@ -103,26 +103,29 @@ class FSP_COMMON_HEADER(Structure):
=0D
class FSP_INFORMATION_HEADER(Structure):=0D
_fields_ =3D [=0D
- ('Signature', ARRAY(c_char, 4)),=0D
- ('HeaderLength', c_uint32),=0D
- ('Reserved1', c_uint16),=0D
- ('SpecVersion', c_uint8),=0D
- ('HeaderRevision', c_uint8),=0D
- ('ImageRevision', c_uint32),=0D
- ('ImageId', ARRAY(c_char, 8)),=0D
- ('ImageSize', c_uint32),=0D
- ('ImageBase', c_uint32),=0D
- ('ImageAttribute', c_uint16),=0D
- ('ComponentAttribute', c_uint16),=0D
- ('CfgRegionOffset', c_uint32),=0D
- ('CfgRegionSize', c_uint32),=0D
- ('Reserved2', c_uint32),=0D
- ('TempRamInitEntryOffset', c_uint32),=0D
- ('Reserved3', c_uint32),=0D
- ('NotifyPhaseEntryOffset', c_uint32),=0D
- ('FspMemoryInitEntryOffset', c_uint32),=0D
- ('TempRamExitEntryOffset', c_uint32),=0D
- ('FspSiliconInitEntryOffset', c_uint32)=0D
+ ('Signature', ARRAY(c_char, 4)),=0D
+ ('HeaderLength', c_uint32),=0D
+ ('Reserved1', c_uint16),=0D
+ ('SpecVersion', c_uint8),=0D
+ ('HeaderRevision', c_uint8),=0D
+ ('ImageRevision', c_uint32),=0D
+ ('ImageId', ARRAY(c_char, 8)),=0D
+ ('ImageSize', c_uint32),=0D
+ ('ImageBase', c_uint32),=0D
+ ('ImageAttribute', c_uint16),=0D
+ ('ComponentAttribute', c_uint16),=0D
+ ('CfgRegionOffset', c_uint32),=0D
+ ('CfgRegionSize', c_uint32),=0D
+ ('Reserved2', c_uint32),=0D
+ ('TempRamInitEntryOffset', c_uint32),=0D
+ ('Reserved3', c_uint32),=0D
+ ('NotifyPhaseEntryOffset', c_uint32),=0D
+ ('FspMemoryInitEntryOffset', c_uint32),=0D
+ ('TempRamExitEntryOffset', c_uint32),=0D
+ ('FspSiliconInitEntryOffset', c_uint32),=0D
+ ('FspMultiPhaseSiInitEntryOffset', c_uint32),=0D
+ ('ExtendedImageRevision', c_uint16),=0D
+ ('Reserved4', c_uint16)=0D
]=0D
=0D
class FSP_PATCH_TABLE(Structure):=0D
@@ -390,7 +393,26 @@ def OutputStruct (obj, indent =3D 0, plen =3D 0):
if IsStrType (val):=0D
rep =3D HandleNameStr (val)=0D
elif IsIntegerType (val):=0D
- rep =3D '0x%X' % val=0D
+ if (key =3D=3D 'ImageRevision'):=0D
+ FspImageRevisionMajor =3D ((val >> 24) & 0xFF)=0D
+ FspImageRevisionMinor =3D ((val >> 16) & 0xFF)=0D
+ FspImageRevisionRevision =3D ((val >> 8) & 0xFF)=0D
+ FspImageRevisionBuildNumber =3D (val & 0xFF)=0D
+ rep =3D '0x%08X' % val=0D
+ elif (key =3D=3D 'ExtendedImageRevision'):=0D
+ FspImageRevisionRevision |=3D (val & 0xFF00)=0D
+ FspImageRevisionBuildNumber |=3D ((val << 8) & 0xFF00)=
=0D
+ rep =3D "0x%04X ('%02X.%02X.%04X.%04X')" % (val, FspIm=
ageRevisionMajor, FspImageRevisionMinor, FspImageRevisionRevision, FspImage=
RevisionBuildNumber)=0D
+ elif field[1] =3D=3D c_uint64:=0D
+ rep =3D '0x%016X' % val=0D
+ elif field[1] =3D=3D c_uint32:=0D
+ rep =3D '0x%08X' % val=0D
+ elif field[1] =3D=3D c_uint16:=0D
+ rep =3D '0x%04X' % val=0D
+ elif field[1] =3D=3D c_uint8:=0D
+ rep =3D '0x%02X' % val=0D
+ else:=0D
+ rep =3D '0x%X' % val=0D
elif isinstance(val, c_uint24):=0D
rep =3D '0x%X' % val.get_value()=0D
elif 'c_ubyte_Array' in str(type(val)):=0D
--=20
2.28.0.windows.1


Re: Error when launching SEV-ES guest with OvmfPkg/AmdSev build

Dov Murik
 

(for the mailing list archives:)

This bug was fixed by commit 36b561623a4b ("OvmfPkg/AmdSev: update the
fdf to use new workarea PCD" by Brijesh Singh).

The fix was merged to edk2 master branch on 2021-10-19:
https://github.com/tianocore/edk2/pull/2080

Thanks Brijesh, Min, Gerd, and Jiewen for your help with this issue.

-Dov

On 13/10/2021 12:35, Dov Murik wrote:
Hello,

I encountered the following problem when trying to launch SEV-ES
(policy=0x5) guests with the OvmfPkg/AmdSev/AmdSevX64 package build:


$ sudo /home/dmurik/git/qemu/build/qemu-system-x86_64 -enable-kvm
-machine q35 -smp 1 -m 2G -machine confidential-guest-support=sev0
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5
-drive
if=pflash,format=raw,unit=0,file=/home/dmurik/git/edk2/Build/AmdSev/DEBUG_GCC5/FV/OVMF.fd,readonly=on
-nographic -global isa-debugcon.iobase=0x402 -debugcon file:ovmf-1.log
-monitor pty

char device redirected to /dev/pts/6 (label compat_monitor0)
error: kvm run failed Invalid argument
EAX=0000000a EBX=0000006f ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT= 00000000 00000000
IDT= 00000000 00000000
CR0=c0000033 CR2=00000000 CR3=00000000 CR4=00000660
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000100
Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ??


ovmf-1.log is empty (even though OVMF is compiled with debug flags).


Plain SEV (no -ES) guests work OK.


The error is "kvm run failed Invalid argument", so I first tried
switching kernels, but 5.11.0, 5.13.0, and 5.14.0 all gave the same result.

Then I tried an older OVMF release (edk2-stable202108) -- and it worked
OK. So I started a git bisect session and found this first bad commit:


commit ab77b6031b03733c28fa5f477d802fd67b3f3ee0
Author: Brijesh Singh <brijesh.singh@amd.com>
Date: Tue Aug 17 21:46:50 2021 +0800

OvmfPkg/ResetVector: update SEV support to use new work area format

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429

Update the SEV support to switch to using the newer work area format.


I wonder if any change in this series should have also touched files in
OvmfPkg/AmdSev and missed them.

Any other ideas on how to debug this are welcome.

Let me know if this should be reported/discussed somewhere else.


Thanks,
-Dov





Re: [PATCH] MdeModulePkg\UfsBlockIoPei: UFS MMIO address size support both 32/64 bit

Wu, Hao A
 

-----Original Message-----
From: Chiu, Ian <Ian.chiu@intel.com>
Sent: Friday, October 22, 2021 5:15 PM
To: devel@edk2.groups.io
Cc: Chiu, Ian <Ian.chiu@intel.com>; Chiu, Ian <Ian.chiu@intel.com>; Chu,
Maggie <maggie.chu@intel.com>; Ni, Ray <ray.ni@intel.com>; Wu, Hao A
<hao.a.wu@intel.com>
Subject: [PATCH] MdeModulePkg\UfsBlockIoPei: UFS MMIO address size
support both 32/64 bit

From: Ian Chiu <Ian.chiu@intel.com>

https://bugzilla.tianocore.org/show_bug.cgi?id=3703
MMIO base address size will overflow while finding two or more Host
controller in the system. Correct it and support 32 and 64 bits address
space.

Could you help to provide the information on what tests have been performed for this patch? Thanks.

Some additional inline comments below:



Signed-off-by: Ian Chiu <ian.chiu@intel.com>
Cc: Maggie Chu <maggie.chu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
---
MdeModulePkg/Bus/Pci/UfsPciHcPei/UfsPciHcPei.c | 37
++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/UfsPciHcPei/UfsPciHcPei.c
b/MdeModulePkg/Bus/Pci/UfsPciHcPei/UfsPciHcPei.c
index 447a05b5b2..69a19c60a2 100644
--- a/MdeModulePkg/Bus/Pci/UfsPciHcPei/UfsPciHcPei.c
+++ b/MdeModulePkg/Bus/Pci/UfsPciHcPei/UfsPciHcPei.c
@@ -76,6 +76,7 @@ InitializeUfsHcPeim (
UINT16 Device;

UINT16 Function;

UINT32 Size;

+ UINT64 MmioSize;

UINT8 SubClass;

UINT8 BaseClass;

UFS_HC_PEI_PRIVATE_DATA *Private;

@@ -119,16 +120,48 @@ InitializeUfsHcPeim (
PciAnd16 (PCI_LIB_ADDRESS (Bus, Device, Function,
PCI_COMMAND_OFFSET), (UINT16)~(EFI_PCI_COMMAND_BUS_MASTER |
EFI_PCI_COMMAND_MEMORY_SPACE));

PciWrite32 (PCI_LIB_ADDRESS (Bus, Device, Function,
PCI_BASE_ADDRESSREG_OFFSET), 0xFFFFFFFF);

Size = PciRead32 (PCI_LIB_ADDRESS (Bus, Device, Function,
PCI_BASE_ADDRESSREG_OFFSET));

+

+ switch (Size & 0x07) {

+ case 0x0:

+ //

+ // Memory space: anywhere in 32 bit address space

+ //

+ MmioSize = (~(Size & 0xFFFFFFF0)) + 1;

+ break;

+ case 0x4:

+ //

+ // Memory space: anywhere in 64 bit address space

+ //

+ MmioSize = Size & 0xFFFFFFF0;

For 64-bit BAR, I think you also need to write 0xFFFFFFFF to the high 32-bit of the BAR and read the return value as well during the calculation of the request MMIO size.


+

+ //

+ // Fix the length to support some spefic 64 bit BAR

Typo: spefic -> specific



+ //

+ Size |= ((UINT32)(-1) << HighBitSet32 (Size));

+

+ //

+ // Calculate the size of 64bit bar

+ //

+ MmioSize |= LShiftU64 ((UINT64) Size, 32);

+ MmioSize = (~(MmioSize)) + 1;

With the above 64-bit BAR size change, I think you need to clean the high 32bits of this 64bit BAR to 0, since 32bit BAR address will be used in PEI phase.



+ break;

+ default:

+ //

+ // Unknown BAR type

+ //

+ ASSERT (FALSE);

+ continue;

+ };

//

// Assign resource to the Ufs Pci host controller's MMIO BAR.

// Enable the Ufs Pci host controller by setting BME and MSE bits of
PCI_CMD register.

//

- PciWrite32 (PCI_LIB_ADDRESS (Bus, Device, Function,
PCI_BASE_ADDRESSREG_OFFSET), (UINT32)(PcdGet32
(PcdUfsPciHostControllerMmioBase) + Size * Private->TotalUfsHcs));

+ PciWrite32 (PCI_LIB_ADDRESS (Bus, Device, Function,
PCI_BASE_ADDRESSREG_OFFSET), (UINT32)(PcdGet32
(PcdUfsPciHostControllerMmioBase) + MmioSize * Private->TotalUfsHcs));

I think the above line can be refined, the driver currently assumes that every UFS HC will have the same request MMIO size (using MmioSize * Private->TotalUfsHcs).
But I do not think this assumption will always be true, it is possible that UFS HCs will have different request MMIO size.



PciOr16 (PCI_LIB_ADDRESS (Bus, Device, Function,
PCI_COMMAND_OFFSET), (EFI_PCI_COMMAND_BUS_MASTER |
EFI_PCI_COMMAND_MEMORY_SPACE));

//

// Record the allocated Mmio base address.

//

- Private->UfsHcPciAddr[Private->TotalUfsHcs] = PcdGet32
(PcdUfsPciHostControllerMmioBase) + Size * Private->TotalUfsHcs;

+ Private->UfsHcPciAddr[Private->TotalUfsHcs] = PcdGet32
(PcdUfsPciHostControllerMmioBase) + (UINTN) MmioSize * Private-
TotalUfsHcs;

Please update the above line accordingly (not assuming UFS HCs having the same request MMIO size).

Best Regards,
Hao Wu



Private->TotalUfsHcs++;

ASSERT (Private->TotalUfsHcs < MAX_UFS_HCS);

}

--
2.16.2.windows.1


MdeModulePkg/DxeCapsuleLibFmp: Use new Variable Lock interface

Yang Jie
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3699
The code in MdeModulePkg\Library\DxeCapsuleLibFmp call the deprecated=20
interface VariableLockRequestToLockc. So I changed the code in
FmpDevicePkg using RegisterBasicVariablePolicy, instead of the=20
deprecated interface.

Signed-off-by: Yang Jie <jie.yang@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
---
.../DxeCapsuleLibFmp/DxeCapsuleLib.inf | 5 +-
.../DxeCapsuleLibFmp/DxeCapsuleReportLib.c | 66 ++++++++++++-------
2 files changed, 47 insertions(+), 24 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf b/MdeM=
odulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
index 05de4299fb..9212c81d68 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
@@ -3,7 +3,7 @@
#=0D
# Capsule library instance for DXE_DRIVER module types.=0D
#=0D
-# Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.<BR>=
=0D
+# Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved.<BR>=
=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
##=0D
@@ -51,6 +51,7 @@
DisplayUpdateProgressLib=0D
FileHandleLib=0D
UefiBootManagerLib=0D
+ VariablePolicyHelperLib=0D
=0D
[Pcd]=0D
gEfiMdeModulePkgTokenSpaceGuid.PcdCapsuleMax =
## CONSUMES=0D
@@ -71,11 +72,11 @@
[Protocols]=0D
gEsrtManagementProtocolGuid ## CONSUMES=0D
gEfiFirmwareManagementProtocolGuid ## CONSUMES=0D
- gEdkiiVariableLockProtocolGuid ## SOMETIMES_CONSUMES=0D
gEdkiiFirmwareManagementProgressProtocolGuid ## SOMETIMES_CONSUMES=0D
gEfiSimpleFileSystemProtocolGuid ## SOMETIMES_CONSUMES=0D
gEfiBlockIoProtocolGuid ## CONSUMES=0D
gEfiDiskIoProtocolGuid ## CONSUMES=0D
+ gEdkiiVariablePolicyProtocolGuid ## CONSUMES=0D
=0D
[Guids]=0D
gEfiFmpCapsuleGuid ## SOMETIMES_CONSUMES ## GUID=0D
diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c b/=
MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c
index 0ec5f20676..665b7d06d9 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c
@@ -1,14 +1,13 @@
/** @file=0D
DXE capsule report related function.=0D
=0D
- Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.<BR>=0D
+ Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved.<BR>=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
=0D
**/=0D
=0D
#include <PiDxe.h>=0D
#include <Protocol/FirmwareManagement.h>=0D
-#include <Protocol/VariableLock.h>=0D
#include <Guid/CapsuleReport.h>=0D
#include <Guid/FmpCapsule.h>=0D
#include <Guid/CapsuleVendor.h>=0D
@@ -26,6 +25,7 @@
#include <Library/ReportStatusCodeLib.h>=0D
#include <Library/DevicePathLib.h>=0D
#include <Library/CapsuleLib.h>=0D
+#include <Library/VariablePolicyHelperLib.h>=0D
=0D
#include <IndustryStandard/WindowsUxCapsule.h>=0D
=0D
@@ -94,6 +94,44 @@ GetNewCapsuleResultIndex (
return CurrentIndex + 1;=0D
}=0D
=0D
+/**=0D
+ Lock Variable by variable policy=0D
+=0D
+ @param[in] VariableGuid The Guid of the variable to be locked=0D
+ @param[in] VariableName The name of the variable to be locked=0D
+**/=0D
+VOID LockVaraible (=0D
+ IN CONST EFI_GUID VariableGuid,=0D
+ IN CHAR16 *VariableName=0D
+ )=0D
+{=0D
+ EFI_STATUS Status;=0D
+ EDKII_VARIABLE_POLICY_PROTOCOL *VariablePolicy;=0D
+=0D
+ // Locate the VariablePolicy protocol=0D
+ Status =3D gBS->LocateProtocol (&gEdkiiVariablePolicyProtocolGuid, NULL,=
(VOID**)&VariablePolicy);=0D
+ if (EFI_ERROR (Status)) {=0D
+ DEBUG ((DEBUG_ERROR, "DxeCapsuleReportLib %a - Could not locate Variab=
lePolicy protocol! %r\n", __FUNCTION__, Status));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ }=0D
+ // If success, go ahead and set the policies to protect the target varia=
bles.=0D
+ Status =3D RegisterBasicVariablePolicy (VariablePolicy,=0D
+ &VariableGuid,=0D
+ VariableName,=0D
+ VARIABLE_POLICY_NO_MIN_SIZE,=0D
+ VARIABLE_POLICY_NO_MAX_SIZE,=0D
+ VARIABLE_POLICY_NO_MUST_ATTR,=0D
+ VARIABLE_POLICY_NO_CANT_ATTR,=0D
+ VARIABLE_POLICY_TYPE_LOCK_NOW);=0D
+ if (EFI_ERROR (Status)) {=0D
+ DEBUG ((DEBUG_ERROR, "DxeCapsuleLibFmp: Failed to lock variable %g %s.=
Status =3D %r\n",=0D
+ &VariableGuid,=0D
+ L"CapsuleLast",=0D
+ Status));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ }=0D
+}=0D
+=0D
/**=0D
Write a new capsule status variable.=0D
=0D
@@ -278,7 +316,7 @@ InitCapsuleMaxVariable (
EFI_STATUS Status;=0D
UINTN Size;=0D
CHAR16 CapsuleMaxStr[sizeof("Capsule####")];=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
+ //EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
=0D
UnicodeSPrint(=0D
CapsuleMaxStr,=0D
@@ -297,11 +335,7 @@ InitCapsuleMaxVariable (
);=0D
if (!EFI_ERROR(Status)) {=0D
// Lock it per UEFI spec.=0D
- Status =3D gBS->LocateProtocol(&gEdkiiVariableLockProtocolGuid, NULL, =
(VOID **)&VariableLock);=0D
- if (!EFI_ERROR(Status)) {=0D
- Status =3D VariableLock->RequestToLock(VariableLock, L"CapsuleMax", =
&gEfiCapsuleReportGuid);=0D
- ASSERT_EFI_ERROR(Status);=0D
- }=0D
+ LockVaraible (gEfiCapsuleReportGuid, L"CapsuleMax");=0D
}=0D
}=0D
=0D
@@ -315,7 +349,6 @@ InitCapsuleLastVariable (
{=0D
EFI_STATUS Status;=0D
EFI_BOOT_MODE BootMode;=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
VOID *CapsuleResult;=0D
UINTN Size;=0D
CHAR16 CapsuleLastStr[sizeof("Capsule####")];=
=0D
@@ -372,11 +405,7 @@ InitCapsuleLastVariable (
}=0D
=0D
// Lock it in normal boot path per UEFI spec.=0D
- Status =3D gBS->LocateProtocol(&gEdkiiVariableLockProtocolGuid, NULL, =
(VOID **)&VariableLock);=0D
- if (!EFI_ERROR(Status)) {=0D
- Status =3D VariableLock->RequestToLock(VariableLock, L"CapsuleLast",=
&gEfiCapsuleReportGuid);=0D
- ASSERT_EFI_ERROR(Status);=0D
- }=0D
+ LockVaraible (gEfiCapsuleReportGuid, L"CapsuleLast");=0D
}=0D
}=0D
=0D
@@ -436,20 +465,13 @@ InitCapsuleRelocationInfo (
VOID=0D
)=0D
{=0D
- EFI_STATUS Status;=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
-=0D
CoDClearCapsuleRelocationInfo();=0D
=0D
//=0D
// Unlock Capsule On Disk relocation Info variable only when Capsule On =
Disk flag is enabled=0D
//=0D
if (!CoDCheckCapsuleOnDiskFlag()) {=0D
- Status =3D gBS->LocateProtocol (&gEdkiiVariableLockProtocolGuid, NULL,=
(VOID **) &VariableLock);=0D
- if (!EFI_ERROR (Status)) {=0D
- Status =3D VariableLock->RequestToLock (VariableLock, COD_RELOCATION=
_INFO_VAR_NAME, &gEfiCapsuleVendorGuid);=0D
- ASSERT_EFI_ERROR (Status);=0D
- }=0D
+ LockVaraible (gEfiCapsuleVendorGuid, COD_RELOCATION_INFO_VAR_NAME);=0D
}=0D
}=0D
=0D
--=20
2.26.2.windows.1


Re: [PATCH V2 12/28] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VE exception #ve

Gerd Hoffmann
 

On Tue, Oct 26, 2021 at 05:06:21AM +0000, Xu, Min M wrote:
On October 12, 2021 6:27 PM, Gerd Hoffmann wrote:
+ if (ExceptionType == VE_EXCEPTION) {
+ EFI_STATUS Status;
+ //
+ // #VE needs to be handled immediately upon enabling exception handling
+ // and therefore can't use the RegisterCpuInterruptHandler() interface.
Can please you explain in more detail why this is the case?
VE Exception may happen before a component registers exception.

So it has to be implemented inside the exception lib.
Well, no, you can also change the code to avoid triggering an exception.

Adding a new lib for the exception means the lib must be added into each
and every *.dsc file (either the tdx impl or the null variant), not only
in the tianocore core itself but also all projects depending on tianocore.

So IMHO it is worth checking out how much effort it would be to avoid
early (before component registration) exceptions.

Which early exception do actually happen?

take care,
Gerd


MdeModulePkg/DxeCapsuleLibFmp: Use new Variable Lock interface

Yang Jie
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3699
The code in MdeModulePkg\Library\DxeCapsuleLibFmp call the deprecated=20
interface VariableLockRequestToLockc. So I changed the code in
FmpDevicePkg using RegisterBasicVariablePolicy, instead of the=20
deprecated interface.

Signed-off-by: Yang Jie <jie.yang@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
---
.../DxeCapsuleLibFmp/DxeCapsuleLib.inf | 5 +-
.../DxeCapsuleLibFmp/DxeCapsuleReportLib.c | 66 ++++++++++++-------
2 files changed, 47 insertions(+), 24 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf b/MdeM=
odulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
index 05de4299fb..9212c81d68 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
@@ -3,7 +3,7 @@
#=0D
# Capsule library instance for DXE_DRIVER module types.=0D
#=0D
-# Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.<BR>=
=0D
+# Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved.<BR>=
=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
##=0D
@@ -51,6 +51,7 @@
DisplayUpdateProgressLib=0D
FileHandleLib=0D
UefiBootManagerLib=0D
+ VariablePolicyHelperLib=0D
=0D
[Pcd]=0D
gEfiMdeModulePkgTokenSpaceGuid.PcdCapsuleMax =
## CONSUMES=0D
@@ -71,11 +72,11 @@
[Protocols]=0D
gEsrtManagementProtocolGuid ## CONSUMES=0D
gEfiFirmwareManagementProtocolGuid ## CONSUMES=0D
- gEdkiiVariableLockProtocolGuid ## SOMETIMES_CONSUMES=0D
gEdkiiFirmwareManagementProgressProtocolGuid ## SOMETIMES_CONSUMES=0D
gEfiSimpleFileSystemProtocolGuid ## SOMETIMES_CONSUMES=0D
gEfiBlockIoProtocolGuid ## CONSUMES=0D
gEfiDiskIoProtocolGuid ## CONSUMES=0D
+ gEdkiiVariablePolicyProtocolGuid ## CONSUMES=0D
=0D
[Guids]=0D
gEfiFmpCapsuleGuid ## SOMETIMES_CONSUMES ## GUID=0D
diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c b/=
MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c
index 0ec5f20676..665b7d06d9 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c
@@ -1,14 +1,13 @@
/** @file=0D
DXE capsule report related function.=0D
=0D
- Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.<BR>=0D
+ Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved.<BR>=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
=0D
**/=0D
=0D
#include <PiDxe.h>=0D
#include <Protocol/FirmwareManagement.h>=0D
-#include <Protocol/VariableLock.h>=0D
#include <Guid/CapsuleReport.h>=0D
#include <Guid/FmpCapsule.h>=0D
#include <Guid/CapsuleVendor.h>=0D
@@ -26,6 +25,7 @@
#include <Library/ReportStatusCodeLib.h>=0D
#include <Library/DevicePathLib.h>=0D
#include <Library/CapsuleLib.h>=0D
+#include <Library/VariablePolicyHelperLib.h>=0D
=0D
#include <IndustryStandard/WindowsUxCapsule.h>=0D
=0D
@@ -94,6 +94,44 @@ GetNewCapsuleResultIndex (
return CurrentIndex + 1;=0D
}=0D
=0D
+/**=0D
+ Lock Variable by variable policy=0D
+=0D
+ @param[in] VariableGuid The Guid of the variable to be locked=0D
+ @param[in] VariableName The name of the variable to be locked=0D
+**/=0D
+VOID LockVaraible (=0D
+ IN CONST EFI_GUID VariableGuid,=0D
+ IN CHAR16 *VariableName=0D
+ )=0D
+{=0D
+ EFI_STATUS Status;=0D
+ EDKII_VARIABLE_POLICY_PROTOCOL *VariablePolicy;=0D
+=0D
+ // Locate the VariablePolicy protocol=0D
+ Status =3D gBS->LocateProtocol (&gEdkiiVariablePolicyProtocolGuid, NULL,=
(VOID**)&VariablePolicy);=0D
+ if (EFI_ERROR (Status)) {=0D
+ DEBUG ((DEBUG_ERROR, "DxeCapsuleReportLib %a - Could not locate Variab=
lePolicy protocol! %r\n", __FUNCTION__, Status));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ }=0D
+ // If success, go ahead and set the policies to protect the target varia=
bles.=0D
+ Status =3D RegisterBasicVariablePolicy (VariablePolicy,=0D
+ &VariableGuid,=0D
+ VariableName,=0D
+ VARIABLE_POLICY_NO_MIN_SIZE,=0D
+ VARIABLE_POLICY_NO_MAX_SIZE,=0D
+ VARIABLE_POLICY_NO_MUST_ATTR,=0D
+ VARIABLE_POLICY_NO_CANT_ATTR,=0D
+ VARIABLE_POLICY_TYPE_LOCK_NOW);=0D
+ if (EFI_ERROR (Status)) {=0D
+ DEBUG ((DEBUG_ERROR, "DxeCapsuleLibFmp: Failed to lock variable %g %s.=
Status =3D %r\n",=0D
+ &VariableGuid,=0D
+ L"CapsuleLast",=0D
+ Status));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ }=0D
+}=0D
+=0D
/**=0D
Write a new capsule status variable.=0D
=0D
@@ -278,7 +316,7 @@ InitCapsuleMaxVariable (
EFI_STATUS Status;=0D
UINTN Size;=0D
CHAR16 CapsuleMaxStr[sizeof("Capsule####")];=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
+ //EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
=0D
UnicodeSPrint(=0D
CapsuleMaxStr,=0D
@@ -297,11 +335,7 @@ InitCapsuleMaxVariable (
);=0D
if (!EFI_ERROR(Status)) {=0D
// Lock it per UEFI spec.=0D
- Status =3D gBS->LocateProtocol(&gEdkiiVariableLockProtocolGuid, NULL, =
(VOID **)&VariableLock);=0D
- if (!EFI_ERROR(Status)) {=0D
- Status =3D VariableLock->RequestToLock(VariableLock, L"CapsuleMax", =
&gEfiCapsuleReportGuid);=0D
- ASSERT_EFI_ERROR(Status);=0D
- }=0D
+ LockVaraible (gEfiCapsuleReportGuid, L"CapsuleMax");=0D
}=0D
}=0D
=0D
@@ -315,7 +349,6 @@ InitCapsuleLastVariable (
{=0D
EFI_STATUS Status;=0D
EFI_BOOT_MODE BootMode;=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
VOID *CapsuleResult;=0D
UINTN Size;=0D
CHAR16 CapsuleLastStr[sizeof("Capsule####")];=
=0D
@@ -372,11 +405,7 @@ InitCapsuleLastVariable (
}=0D
=0D
// Lock it in normal boot path per UEFI spec.=0D
- Status =3D gBS->LocateProtocol(&gEdkiiVariableLockProtocolGuid, NULL, =
(VOID **)&VariableLock);=0D
- if (!EFI_ERROR(Status)) {=0D
- Status =3D VariableLock->RequestToLock(VariableLock, L"CapsuleLast",=
&gEfiCapsuleReportGuid);=0D
- ASSERT_EFI_ERROR(Status);=0D
- }=0D
+ LockVaraible (gEfiCapsuleReportGuid, L"CapsuleLast");=0D
}=0D
}=0D
=0D
@@ -436,20 +465,13 @@ InitCapsuleRelocationInfo (
VOID=0D
)=0D
{=0D
- EFI_STATUS Status;=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
-=0D
CoDClearCapsuleRelocationInfo();=0D
=0D
//=0D
// Unlock Capsule On Disk relocation Info variable only when Capsule On =
Disk flag is enabled=0D
//=0D
if (!CoDCheckCapsuleOnDiskFlag()) {=0D
- Status =3D gBS->LocateProtocol (&gEdkiiVariableLockProtocolGuid, NULL,=
(VOID **) &VariableLock);=0D
- if (!EFI_ERROR (Status)) {=0D
- Status =3D VariableLock->RequestToLock (VariableLock, COD_RELOCATION=
_INFO_VAR_NAME, &gEfiCapsuleVendorGuid);=0D
- ASSERT_EFI_ERROR (Status);=0D
- }=0D
+ LockVaraible (gEfiCapsuleVendorGuid, COD_RELOCATION_INFO_VAR_NAME);=0D
}=0D
}=0D
=0D
--=20
2.26.2.windows.1


Re: [PATCH V2 28/28] OvmfPkg: Add LocalApicTimerDxe

Gerd Hoffmann
 

I still think we don't need a runtime switch. Continue using 8254TimerDxe for
CSM_ENABLE=TRUE builds should be enough.
Thanks for your detailed explanation. I agree we don't need a runtime switch. Just use CSM_ENABLE=TRUE in *.dsc/*.fdf to switch 8254 and lapic in build time.
I will submit a separate patch series for this change.

There are 4 .dsc which include the 8254Timer.
- OvmfPkg/AmdSev/AmdSevX64.dsc
- OvmfPkg/OvmfPkgIa32.dsc
- OvmfPkg/OvmfPkgIa32X64.dsc
- OvmfPkg/OvmfPkgX64.dsc

Do you think we should apply the changes to all above 4 .dsc?
For the AmdSev config it doesn't make sense to support a CSM.
So I' suggest to just remove support for CSM_ENABLE=TRUE (separate
patch), then use the lapic timer unconditionally.

For the three OvmfPkg* configs using 8254TimerDxe with CSM_ENABLE=TRUE
and LapicTimerDxe otherwise is fine.

take care,
Gerd


Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, October 26, 2021 #cal-cancelled

devel@edk2.groups.io Calendar <noreply@...>
 

Cancelled: TianoCore Bug Triage - APAC / NAMO

This event has been cancelled.

When:
Tuesday, October 26, 2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


回复: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 10/26/2021 #cal-reminder

gaoliming
 

Few new issues are reported this week. Let’s cancel the meeting.

 

3704

EDK2

Code

unassigned@...

UNCO

OvmfPkgX64 RELEASE build fails with clang-13.

Thu 05:28

krichanov@...

3702

EDK2 Cod

Specific

unassigned@...

UNCO

Code First - BGRT table "valid" field typo

Wed 19:28

samer.el-haj-mahmoud@...

3701

EDK2 Cod

Specific

unassigned@...

UNCO

Code first - Fix incorrect reference to "Memory Aggregator Device"

Wed 18:40

samer.el-haj-mahmoud@...

3693

EDK2

Code

unassigned@...

UNCO

FL1100 usb chipset/Mac OS OVMF/XhciDxe issues with bootable usb 3.0 devices

2021-10-18

crudo.daniele@...

Thanks

Liming

 

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 devel@edk2.groups.io Calendar
发送时间: 20211026 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 10/26/2021 #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
10/26/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: [PATCH V2 12/28] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VE exception #ve

Min Xu
 

On October 12, 2021 6:27 PM, Gerd Hoffmann wrote:
+ if (ExceptionType == VE_EXCEPTION) {
+ EFI_STATUS Status;
+ //
+ // #VE needs to be handled immediately upon enabling exception handling
+ // and therefore can't use the RegisterCpuInterruptHandler() interface.
Can please you explain in more detail why this is the case?
VE Exception may happen before a component registers exception. So it has to be implemented inside the exception lib.

Thanks.
Min


Event: TianoCore Bug Triage - APAC / NAMO - 10/26/2021 #cal-reminder

devel@edk2.groups.io Calendar <noreply@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
10/26/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: [PATCH V2 28/28] OvmfPkg: Add LocalApicTimerDxe

Min Xu
 

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

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

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

So, first I'd suggest to just use that (maybe rename the thing to
avoid confusion as it isn't really Xen specific).
Thanks for reminder. We can use XenTimerDxe as the LocalApicTimerDxe in
Tdx guest. There will be a separate patch to rename XenTimerDxe to
LocalApicTimerDxe in the next version.

You can also split this off into a separate patch series as it shouldn't have any tdx
dependency.

I am not quite sure if there will be any side effect if we switch ovmf
(X64) from 8254 to lapic unconditionally. Quick smoke test does show
no obvious problems (EDK2 CI shows no error either). But since 8254
timer has already been used in OvmfPkgX64, then there always a reason
why 8254 is used.
Note that 8254TimerDxe was not written for OVMF, it was moved over from
PcAtChipsetPkg to OvmfPkg in 2019. Probably because OVMF was the only user
left.

Most likely the reason OVMF used 8254TimerDxe initially was that it could just
use the existing driver in PcAtChipsetPkg. And it simply hasn't been changed ever.

Hmm, CSM support was moved in 2019 too, checking ...

Yes, CSM support depends on 8254 (and 8259) drivers.

I am thinking if it is a more secure way to introduce PcdTimerSelector
(to select timer in run-time) this time. We can revisit this proposal
(switch ovmf from 8254 to lapic unconditionally) when we are pretty
sure there is no side effect in the future.
I still think we don't need a runtime switch. Continue using 8254TimerDxe for
CSM_ENABLE=TRUE builds should be enough.
Thanks for your detailed explanation. I agree we don't need a runtime switch. Just use CSM_ENABLE=TRUE in *.dsc/*.fdf to switch 8254 and lapic in build time.
I will submit a separate patch series for this change.

There are 4 .dsc which include the 8254Timer.
- OvmfPkg/AmdSev/AmdSevX64.dsc
- OvmfPkg/OvmfPkgIa32.dsc
- OvmfPkg/OvmfPkgIa32X64.dsc
- OvmfPkg/OvmfPkgX64.dsc

Do you think we should apply the changes to all above 4 .dsc?

Thanks
Min


Re: [edk2-platforms][PATCH V1 02/11] CometlakeOpenBoardPkg/ReportFvLib: Switch to new library instances.

Kathappan Esakkithevar
 

Reviewed-by: Kathappan Esakkithevar <kathappan.esakkithevar@intel.com>

-----Original Message-----
From: Oram, Isaac W <isaac.w.oram@intel.com>
Sent: Saturday, October 16, 2021 2:55 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@intel.com>; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Chaganty, Rangasai V
<rangasai.v.chaganty@intel.com>; Kethi Reddy, Deepika
<deepika.kethi.reddy@intel.com>; Esakkithevar, Kathappan
<kathappan.esakkithevar@intel.com>
Subject: [edk2-devel][edk2-platforms][PATCH V1 02/11]
CometlakeOpenBoardPkg/ReportFvLib: Switch to new library instances.

MinPlatformPkg shared ReportFvLib has split into PEI and SMM instances.
Default versions are already included via CorePeiLib.dsc and CoreDxeLib.dsc

Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Deepika Kethi Reddy <deepika.kethi.reddy@intel.com>
Cc: Kathappan Esakkithevar <kathappan.esakkithevar@intel.com>
Signed-off-by: Isaac Oram <isaac.w.oram@intel.com>
---

Platform/Intel/CometlakeOpenBoardPkg/CometlakeURvp/OpenBoardPkg.d
sc | 1 -
1 file changed, 1 deletion(-)

diff --git
a/Platform/Intel/CometlakeOpenBoardPkg/CometlakeURvp/OpenBoardPkg
.dsc
b/Platform/Intel/CometlakeOpenBoardPkg/CometlakeURvp/OpenBoardPkg
.dsc
index 44a1bd54d6..3a92eb4575 100644
---
a/Platform/Intel/CometlakeOpenBoardPkg/CometlakeURvp/OpenBoardPkg
.dsc
+++
b/Platform/Intel/CometlakeOpenBoardPkg/CometlakeURvp/OpenBoardPkg
.dsc
@@ -121,7 +121,6 @@

PciSegmentInfoLib|$(PLATFORM_PACKAGE)/Pci/Library/PciSegmentInfoLibS
imple/PciSegmentInfoLibSimple.inf
PeiLib|$(PLATFORM_PACKAGE)/Library/PeiLib/PeiLib.inf

PlatformBootManagerLib|$(PLATFORM_PACKAGE)/Bds/Library/DxePlatfor
mBootManagerLib/DxePlatformBootManagerLib.inf
-
ReportFvLib|$(PLATFORM_PACKAGE)/PlatformInit/Library/PeiReportFvLib/P
eiReportFvLib.inf

TestPointCheckLib|$(PLATFORM_PACKAGE)/Test/Library/TestPointCheckLib
Null/TestPointCheckLibNull.inf

#######################################
--
2.27.0.windows.1


Inclusive Language RFC

Teng, Lynn L
 

Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05). Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan

1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages
3. Scrubbing all non-legacy code
3.1. Integrate open-source commit hook that will warn submitter of violations
4. Working with UEFI to scrub legacy code
4.1. Update commit hook to block submissions with violations


## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted

Or similar descriptive terminology


Call for Topics - Community Meeting Nov 4

Teng, Lynn L
 

Hello All,

Please let me know by October 29th if you have any topics you would like to include in the agenda for the November 4th Community Meeting.

Thank you,
Lynn Teng


Re: [edk2-libc Patch 1/1] AppPkg/Applications/Python: Remove py2.7.2 support from edk2-libc

Jayaprakash, N
 

Hi Mike,

I have send V2 version of patch series to remove complete Py 2.7 support(including py 2.7.2 and py 2.7.10 versions removal).
Separate patches created for code and document changes.

There was some issue with running send email on my system, you would have got multiple emails with the same set of patches.
Please ignore the duplicate patch emails.

These are the patches sent for removing py 2.7 support completely from edk2-libc.
AppPkg/Applications/Python: To remove the py2.7.2 uefi port code - Code changes 2.7.2
AppPkg/Applications/Python: to remove document references to py2.7.2 - Document changes 2.7.2
AppPkg/Applications/Python: to remove py2.7.10 support from edk2-libc - Code changes 2.7.10
AppPkg/Applications/Python: to remove py2.7.10 references from edk2-libc - Document changes 2.7.10

Please review and do the needful.

Regards,
JP

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: 23 October 2021 22:40
To: Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Rebecca Cran <rebecca@nuviainc.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python: Remove py2.7.2 support from edk2-libc

Can you please send V2 of the patch series with the Readme changes in its own patch?

Thanks,

Mike

-----Original Message-----
From: Jayaprakash, N <n.jayaprakash@intel.com>
Sent: Friday, October 22, 2021 4:23 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>;
devel@edk2.groups.io
Cc: Rebecca Cran <rebecca@nuviainc.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1]
AppPkg/Applications/Python: Remove py2.7.2 support from edk2-libc

Hi Mike,

Could you look into this and let me know if there is anything else need to be done.

Regards,
JP
-----Original Message-----
From: Jayaprakash, N
Sent: 20 October 2021 23:15
To: Kinney, Michael D <michael.d.kinney@intel.com>;
devel@edk2.groups.io
Cc: Rebecca Cran <rebecca@nuviainc.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1]
AppPkg/Applications/Python: Remove py2.7.2 support from edk2-libc

Hi Mike,

Thanks for the review comments.

The PythonReadMe.txt available @ https://github.com/tianocore/edk2-
libc/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
is the readme file for Py2.7.2 and we don't need to retain this file.
So I have deleted this file as part of the patch sent for review.

Py 2.7.10 and Py 3.6.8 have their respective readme files as
Py2710ReadMe.txt @ https://github.com/jpshivakavi/edk2-
libc/tree/master/AppPkg/Applications/Python/Python-2.7.10
Py368ReadMe.txt @
https://github.com/jpshivakavi/edk2-libc/tree/master/AppPkg/Applicatio
ns/Python/Python-3.6.8


Besides this, I have taken care of all the other documentation changes
required as given below

Updated the readme.md file from this location and removed the
reference to Py2.7.2 license
https://github.com/tianocore/edk2-libc/blob/master/Readme.md

AppPkg/Applications/Python/Python-2.7.2/Tools/pybench
AppPkg/Applications/Python/Python-2.7.2

Updated the readme.txt from the below location to remove references to 2.7.2 and replace it with 3.6.8 references.
https://github.com/tianocore/edk2-libc/blob/master/AppPkg/ReadMe.txt
Also updated the version of this readme file along with the date
Version 1.03
18 Oct. 2021


Besides documentation changes following changes have been done to
delete py 2.7.2 support from edk2-libc Updated the AppPkg.dsc file to remove the Python 2.7.2 inf references.
https://github.com/jpshivakavi/edk2-libc/blob/remove_py272_support/App
Pkg/AppPkg.dsc


Removed all files and folders corresponding to Py2.7.2 support from
https://github.com/jpshivakavi/edk2-libc/tree/master/AppPkg/Applicatio
ns/Python
Efi\
Ia32\
PyMod-2.7.2\
Python-2.7.2\
X64\
PythonCore.inf // Inf file for py 2.7.2
PythonReadme.txt // Readme file for Py 2.7.2


Let me know if there is anything else needed.

Regards,
JP

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: 20 October 2021 21:35
To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>;
Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Rebecca Cran <rebecca@nuviainc.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1]
AppPkg/Applications/Python: Remove py2.7.2 support from edk2-libc

Hi JP,

Can you also update the documentation to remove references to Python 2.x or update for Python 3.x?

For example, the following file has Python 2.x references.

https://github.com/tianocore/edk2-libc/blob/master/AppPkg/Applications
/Python/PythonReadMe.txt

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Jayaprakash, N
Sent: Tuesday, October 19, 2021 8:43 PM
To: devel@edk2.groups.io
Cc: Rebecca Cran <rebecca@nuviainc.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Jayaprakash, N
<n.jayaprakash@intel.com>
Subject: [edk2-devel] [edk2-libc Patch 1/1]
AppPkg/Applications/Python: Remove py2.7.2 support from edk2-libc





[edk2-libc Patch v2 4/4] AppPkg/Applications/Python: to remove py2.7.10 references from edk2-libc

Jayaprakash, N
 

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

This commit is to remove the document references to py 2.7.10
UEFI port. Py2.7.10 is no more supported as it has reached EOL
starting from 1st Jan 2020. You may use the version py 3.6.8
available for uefi shell from edk2-libc.

Cc: Rebecca Cran <rebecca@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
---
Readme.md | 1 -
1 file changed, 1 deletion(-)

diff --git a/Readme.md b/Readme.md
index f0e9501..2d7690d 100644
--- a/Readme.md
+++ b/Readme.md
@@ -22,7 +22,6 @@ The majority of the content in the EDK II open source project uses a
[BSD-2-Clause Plus Patent License](License.txt). The EDK II open source project
contains the following components that are covered by additional licenses:

-* [AppPkg/Applications/Python/Python-2.7.10](AppPkg/Applications/Python/Python-2.7.10/LICENSE)
* [AppPkg/Applications/Python/Python-3.6.8](AppPkg/Applications/Python/Python-3.6.8/LICENSE)

The EDK II LIBC Project is composed of packages. The maintainers for each
--
2.32.0.windows.2


[edk2-libc Patch v2 3/4] AppPkg/Applications/Python: to remove py2.7.10 support from edk2-libc

Jayaprakash, N
 

7101 - 7120 of 89693