Hi Liming,
There are 2 issues that I would like to recommend get committed for the
edk2-stable20211 tag.
The code reviews were sent on the Soft Freeze start day, so I want to follow
the approval process.
Here are the details:
1) https://bugzilla.tianocore.org/show_bug.cgi?id=3722
* Code
Reviewed-by: Jiewen Yao
> -Original Message-
> From: Gerd Hoffmann
> Sent: Tuesday, November 9, 2021 3:01 PM
> To: Kinney, Michael D
> Cc: devel@edk2.groups.io; Anthony Perard ; Julien
> Grall ; Ard Biesheuvel ; Yao,
> Jiewen ; Justen, Jordan L
> Subject: Re: [Patch 1/1] OvmfPkg/Xen:
Remove DXE version as the library isn't in use.
Simplify the SMM library. Remove functions calling functions.
Cc: Nate DeSimone
Cc: Chasel Chiu
Signed-off-by: Isaac Oram
---
Platform/Intel/WhitleyOpenBoardPkg/Library/BoardAcpiLib/DxeBoardAcpiTableLib.c
| 37 --
From: Bret Barkelew
In order to separate this libary into architecture-specific versions,
first create a NULL implementation that can pass CI on any arch.
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc: Jiewen Yao
Cc: Supreeth Venkatesh
Cc: Sean Brogan
Signed-off-by: Bret Barkelew
---
From: Bret Barkelew
This aligns better with Mu's philosophy around dependency structuring
and is one of the steps to enable Basecore to have zero CI dependencies
on other Mu repos.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3652
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar
From: Bret Barkelew
This aligns better with Mu's philosophy around dependency structuring
and is one of the steps to enable Basecore to have zero CI dependencies
on other Mu repos.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3652
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar
From: Bret Barkelew
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3651
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc: Jiewen Yao
Cc: Supreeth Venkatesh
Cc: Sean Brogan
Signed-off-by: Bret Barkelew
---
From: Sean Brogan
After adding the abstract MmuLib to MdePkg, add an implementation
backed by the existing ArmMmuLib to ArmPkg.
This implementation is currently just a shim to the
old library, while enabling higher-level code to be more
common.
REF:
From: Bret Barkelew
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3651
Cc: Jian J Wang
Cc: Liming Gao
Cc: Dandan Bi
Cc: Liming Gao
Cc: Sean Brogan
Signed-off-by: Bret Barkelew
---
MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c | 4 ++--
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
From: Bret Barkelew
There are a number of Arm-specific accesses that are abstracted
behind this. It may need to be refactored to work better across
architectures.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3651
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Cc: Sean Brogan
From: Bret Barkelew
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Cc: Sean Brogan
Signed-off-by: Bret Barkelew
Reviewed-by: Leif Lindholm
---
{ArmPkg/Include => MdePkg/Include/AArch64}/AsmMacroIoLibV8.h | 0
{ArmPkg/Include =>
From: Bret Barkelew
This aligns better with Mu's philosophy around dependency structuring
and is one of the steps to enable Basecore to have zero CI dependencies
on other Mu repos.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3650
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Bob Feng
Cc:
From: Bret Barkelew
This aligns better with Mu's philosophy around dependency structuring
and is one of the steps to enable Basecore to have zero CI dependencies
on other Mu repos.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3649
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Michael D
From: Bret Barkelew
This extra interface is redundant and unnecessary. Dropping it is
more EDK2-ish.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3647
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sean Brogan
Signed-off-by: Bret Barkelew
Reviewed-by: Leif Lindholm
---
ArmPkg/ArmPkg.dec
From: Bret Barkelew
StandaloneMmMmuLib has been turned into an implementation of the
ArmMmuLib class (without any change to the interface itself), so
this module can now change its dependency.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3647
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc:
From: Bret Barkelew
Drop switch from the custom "StandaloneMmMmuLib" class to the
more generic "ArmMmuLib" class and add the missing functions
to fulfill that interface.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3647
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sean Brogan
From: Bret Barkelew
Not sure what all module types this HAS been validated against, but it
doesn't work with STANDALONE_MM or STANDALONE_MM_CORE.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3647
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sean Brogan
Signed-off-by: Bret Barkelew
This series of patch commits moves a number of modules and libraries around in
order
to better un-silo the Arm-specific code. Unnecessary abstractions were removed,
some
duplicate code was abstracted, and generally things were cleaned up so that
common
code (e.g. MdePkg, MdeModulePkg,
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3625
DxeTpmMeasurementLib supports TPM based measurement in DXE phase.
After CcMeasurementProtocol is introduced, CC based measurement needs
to be supported in DxeTpmMeasurementLib as well.
A platform should have only one RTS/RTR. Only one of
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3625
DxeTpm2MeasureBootLib supports TPM2 based measure boot. After
CcMeasurementProtocol is introduced, CC based measure boot needs to
be supported in DxeTpm2MeasureBootLib as well.
There are 2 major changes in this commit.
1. A platform should
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3625
CC guest is a Confidential Computing guest. If CC Guest firmware
supports measurement and an event is created, CC Guest firmware
is designed to report the event log with the same data structure
in TCG-Platform-Firmware-Profile specification
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3625
If Confidential Computing (Cc) firmware supports measurement and an
event is created, CC-Guest firmware is designed to report the event
log with the same data structure in TCG-Platform-Firmware-Profile
specification with
From: Tom Lendacky
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Use the SEV-SNP AP Creation NAE event to create and launch APs under
SEV-SNP. This capability will be advertised in the SEV Hypervisor
Feature Support PCD (PcdSevEsHypervisorFeatures).
Cc: Michael Roth
Cc: Eric Dong
When SEV-SNP is active, the CPUID and Secrets memory range contains the
information that is used during the VM boot. The content need to be persist
across the kexec boot. Mark the memory range as Reserved in the EFI map
so that guest OS or firmware does not use the range as a system RAM.
Cc:
The SetMemoryEncDec() is used by the higher level routines to set or clear
the page encryption mask for system RAM and Mmio address. When SEV-SNP is
active, in addition to set/clear page mask it also updates the RMP table.
The RMP table updates are required for the system RAM address and not
the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Version 2 of the GHCB specification added a new VMGEXIT that the guest
could use for querying the hypervisor features. One of the immediate
users for it will be an AP creation code. When SEV-SNP is enabled, the
guest can use the newly added
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Now that both the secrets and cpuid pages are reserved in the HOB,
extract the location details through fixed PCD and make it available
to the guest OS through the configuration table.
Cc: Michael Roth
Cc: James Bottomley
Cc: Min Xu
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Version 2 of the GHCB specification added the support to query the
hypervisor feature bitmap. The feature bitmap provide information
such as whether to use the AP create VmgExit or use the AP jump table
approach to create the APs. The
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Previous commit introduced a generic confidential computing PCD that can
determine whether AMD SEV-ES is enabled. Update the MpInitLib to drop the
PcdSevEsIsEnabled in favor of PcdConfidentialComputingAttr.
Cc: Michael Roth
Cc: Ray Ni
Cc:
From: Michael Roth
During AP bringup, just after switching to long mode, APs will do some
cpuid calls to verify that the extended topology leaf (0xB) is available
so they can fetch their x2 APIC IDs from it. In the case of SEV-ES,
these cpuid instructions must be handled by direct use of the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The MemEncryptSev{Set,Clear}PageEncMask() functions are used to set or
clear the memory encryption attribute in the page table. When SEV-SNP
is active, we also need to change the page state in the RMP table so that
it is in sync with the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Many of the integrity guarantees of SEV-SNP are enforced through the
Reverse Map Table (RMP). Each RMP entry contains the GPA at which a
particular page of DRAM should be mapped. The guest can request the
hypervisor to add pages in the RMP
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The MpInitLib uses the ConfidentialComputingAttr PCD to determine whether
AMD SEV is active so that it can use the VMGEXITs defined in the GHCB
specification to create APs.
Cc: Michael Roth
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Eric Dong
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
An SEV-SNP guest requires that the physical address of the GHCB must
be registered with the hypervisor before using it. See the GHCB
specification section 2.3.2 for more details.
Cc: Michael Roth
Cc: Eric Dong
Cc: Ray Ni
Cc: Rahul Kumar
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Now that OvmfPkg supports version 2 of the GHCB specification, bump the
protocol version.
Cc: Michael Roth
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Eric Dong
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The VMM launch sequence should have pre-validated all the data pages used
in the Reset vector. The range does not cover the data pages used during
the SEC phase (mainly PEI and DXE firmware volume decompression memory).
When SEV-SNP is
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
While initializing APs, the MpInitLib may need to know whether the
guest is running with active AMD SEV or Intel TDX memory encryption.
Add a new ConfidentialComputingGuestAttr PCD that can be used to query
the memory encryption attribute.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
When SEV-SNP is active, a memory region mapped encrypted in the page
table must be validated before access. There are two approaches that
can be taken to validate the system RAM detected during the PEI phase:
1) Validate on-demand
OR
2)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The MemEncryptSevSnpPreValidateSystemRam() is used for pre-validating the
system RAM. As the boot progress, each phase validates a fixed region of
the RAM. In the PEI phase, the PlatformPei detects all the available RAM
and calls to
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Virtual Machine Privilege Level (VMPL) feature in the SEV-SNP
architecture allows a guest VM to divide its address space into four
levels. The level can be used to provide the hardware isolated
abstraction layers with a VM. The VMPL0 is the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 added support to ensure
that MMIO is only performed against the un-encrypted memory. If MMIO
is performed against encrypted memory, a #GP is raised.
The AmdSevDxe uses the functions provided
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The SEV-SNP guest requires that GHCB GPA must be registered before using.
See the GHCB specification section 2.3.2 for more details.
Cc: Michael Roth
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The initial page built during the SEC phase is used by the
MemEncryptSevSnpValidateSystemRam() for the system RAM validation. The
page validation process requires using the PVALIDATE instruction; the
instruction accepts a virtual address of
From: Michael Roth
SEV-SNP firmware allows a special guest page to be populated with
guest CPUID values so that they can be validated against supported
host features before being loaded into encrypted guest memory to be
used instead of hypervisor-provided values [1].
Add handling for this in
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Create a function that can be used to determine if VM is running as an
SEV-SNP guest.
Cc: Michael Roth
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
Cc: Erdem Aktas
Cc: Gerd
From: Michael Roth
CPUID instructions are issued during early boot to do things like probe
for SEV support. Currently these are handled by a minimal #VC handler
that uses the MSR-based GHCB protocol to fetch the CPUID values from
the hypervisor. When SEV-SNP is enabled, use the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The OvmfPkgX86 build reserves memory regions in MEMFD. The memory regions
get accessed in the SEC phase. AMD SEV-SNP require that the guest's
private memory be accepted or validated before access.
Introduce a Guided metadata structure that
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
In preparation for SEV-SNP support move clearing of the GHCB memory from
the ResetVector/AmdSev.asm to SecMain/AmdSev.c. The GHCB page is not
accessed until SevEsProtocolCheck() switch to full GHCB. So, the move
does not make any changes in
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The SEV-SNP guest requires that GHCB GPA must be registered before using.
See the GHCB specification section 2.3.2 for more details.
Cc: Michael Roth
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
During the SNP guest launch sequence, a special secrets page needs to be
inserted by the VMM. The PSP will populate the page; it will contain the
VM Platform Communication Key (VMPCKs) used by the guest to send and
receive secure messages to
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Platform features and capabilities are traditionally discovered via the
CPUID instruction. Hypervisors typically trap and emulate the CPUID
instruction for a variety of reasons. There are some cases where incorrect
CPUID information can
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
An SEV-SNP guest requires that private memory (aka pages mapped encrypted)
must be validated before being accessed.
The validation process consist of the following sequence:
1) Set the memory encryption attribute in the page table (aka
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Move all the SEV specific function in AmdSev.c.
No functional change intended.
Cc: Eric Dong
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Michael Roth
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
new hardware-based memory protections. SEV-SNP adds strong memory integrity
protection to help prevent malicious hypervisor-based attacks like data
replay, memory
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Move all the SEV specific function in AmdSev.c.
No functional change intended.
Cc: Michael Roth
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
Cc: Erdem Aktas
Cc: Gerd Hoffmann
Will address in next release.
On Thu, Nov 4, 2021 at 5:43 AM Leif Lindholm wrote:
> On Tue, Nov 02, 2021 at 13:17:43 -0700, brbar...@microsoft.com wrote:
> > From: Sean Brogan
> >
> > The previously Arm-specific "ArmMmuLib" has been generalized
> > as "MmuLib". The Arm implementation of this
I've added Mike Kinney and Hao A Wu.
I tested it under OVMF x64 and it worked, but I haven't tested it on IA32.
--
Rebecca Cran
On 11/10/21 11:06 AM, Sami Mujawar wrote:
Hi Rebecca,
Thank you for the updated patch. These changes look good to me.
The INF file mentions support for IA32 and
Hi Rebecca,
Thank you for the updated patch. These changes look good to me.
The INF file mentions support for IA32 and X64 so it would be got to get
feedback for other architectures and from the MdeModulePkg maintainers.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 05/11/2021 08:31
Hi All,
Sorry, my bad for not providing the details. Below is the build
configuration.
Passing: stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=GCC5 TARGET=NOOPT -a IA32,X64
Failing: stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=GCC5 TARGET=NOOPT -a
On 11/9/2021 10:44 AM, Michael D Kinney wrote:
-Original Message-
From: devel@edk2.groups.io On Behalf Of Gerd Hoffmann
Sent: Tuesday, November 9, 2021 6:10 AM
To: Leif Lindholm
Cc: devel@edk2.groups.io; Kinney, Michael D ; Andrew Fish
; Marvin Häuser
; Michael Kubacki ;
How easy it is to push changes to https://www.tianocore.org/ ? I had
thought that given how infrequently it's updated it's rather difficult,
but I agree that's the ideal location for the Doxygen pages. If it's
easier than I think, I have other changes I'd like to make such as
updating
Hi Ard,
Please find my response inline marked [SAMI].
Regards,
Sami Mujawar
On 10/11/2021 11:33 AM, Ard Biesheuvel wrote:
On Wed, 10 Nov 2021 at 12:01, Sami Mujawar wrote:
The first 4 patches in this series fix build breaks in upstream
edk2-platforms code for Socionext, Lemaker and
On Wed, 10 Nov 2021 at 12:01, Sami Mujawar wrote:
>
> The first 4 patches in this series fix build breaks in upstream
> edk2-platforms code for Socionext, Lemaker and SynQuacerEvalBoard.
>
> The IORT Rev E.b specification updates the IORT table revision
> to 3. Following this the IORT table
Hi Liming,
I have resubmitted the new series along with the patches to update
edk2-platforms.
The links for the new series are as below:
https://edk2.groups.io/g/devel/message/83545 [PATCH v3 0/8] IORT Rev E.b
specification updates (
The corresponding patch series to update the platforms in edk2-platforms is
submitted at https://edk2.groups.io/g/devel/message/83555
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83565): https://edk2.groups.io/g/devel/message/83565
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
The IORT Specification E.b updates the IORT table revision to 3. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.
Therefore, update the usage of
EbcDxe is not supported for AArch32 builds of the firmware.
Therefore, move EbcDxe so that it is included only for AArch64
builds of the firmware.
Signed-off-by: Sami Mujawar
---
Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 4 +++-
BdsDxe depends on VariablePolicyHelperLib, so move it out from
VariableRuntimeDxe.inf and add it to LibraryClasses.DXE_DRIVER and
LibraryClasses.DXE_RUNTIME_DRIVER.
This is required to fix the build break in CelloBoard.dsc
Signed-off-by: Sami Mujawar
---
ArmSoftFloatLib is required for the AARCH32 build of the firmware
for SynQuacerEvalBoard.
Therefore, add the missing ArmSoftFloatLib to SynQuacerEvalBoard.dsc
Signed-off-by: Sami Mujawar
---
Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 3 +++
1 file changed, 3 insertions(+)
BdsDxe depends on VariablePolicyHelperLib, so move it out from
VariableRuntimeDxe.inf and add it to LibraryClasses.DXE_DRIVER and
LibraryClasses.DXE_RUNTIME_DRIVER.
This is required to fix the build break in SynQuacerEvalBoard.dsc
Signed-off-by: Sami Mujawar
---
The first 4 patches in this series fix build breaks in upstream
edk2-platforms code for Socionext, Lemaker and SynQuacerEvalBoard.
The IORT Rev E.b specification updates the IORT table revision
to 3. Following this the IORT table revision macro
EFI_ACPI_IO_REMAPPING_TABLE_REVISION which was at
Bugzilla: 3458 - Add support IORT Rev E.b specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.b,
Feb 2021 (https://developer.arm.com/documentation/den0049/)
introduces the following updates,
The IORT generator is populating the reference field for Context and
PMU interrupts even if their count is zero.
Update the IORT generator to set the references only if the interrupt
count is not 0. Also add checks to ensure a valid reference token has
been provided.
Signed-off-by: Sami Mujawar
The IORT table generator is setting up a reference to ID array for
nodes even when the ID Mapping count is zero. This is not an issue as an
OS would only access the ID Reference if the ID mapping count is not zero.
However, it would be good to set the reference to ID array to zero when
the ID
Add error handling when the IdMappingCount is not zero and the
IdMappingToken is NULL.
Signed-off-by: Sami Mujawar
---
Notes:
v3:
- New patch in this series. Moves error handling code for [SAMI]
IdMappingToken from patch v2 6/8 and v2 8/8 into this
patch.
Ref:
Bugzilla: 3458 - Add support IORT Rev E.b specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.b,
Feb 2021 (https://developer.arm.com/documentation/den0049/)
introduces the following updates,
Some field names in the IORT table parser were longer than the
OUTPUT_FIELD_COLUMN_WIDTH plus indentation, resulting in loss of
the output print alignment. Therefore, abbreviate the field names.
Signed-off-by: Sami Mujawar
Reviewed-by: Zhichao Gao
Reviewed-by: Pierre Gondois
---
Notes:
Bugzilla: 3458 - Add support IORT Rev E.b specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.b,
Feb 2021 (https://developer.arm.com/documentation/den0049/)
introduces the following updates,
Bugzilla: 3458 - Add support IORT Rev E.b specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table (IORT) specification has been updated to
rev E.b. The following updates are introduced including the errata
to rev E and E.a:
- increments the
Bugzilla: 3458 - Add support IORT Rev E.b specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.b,
Feb 2021 (https://developer.arm.com/documentation/den0049/)
introduces the following updates,
Hi Min,
Sorry for the late review. My comments and a few questions are inline.
Thanks
-Erdem
On Mon, Nov 1, 2021 at 6:16 AM Min Xu wrote:
>
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>
> +**/
> +UINT32
> +GetGpaPageLevel (
> + UINT32 PageSize
> + )
> +{
> + UINT32
> 5) Indent relative to the last indentation, not to symbol names, i.e.
>
> Status = Function (
> A
> );
>
> instead of
>
> Status = Function (
> A
> );
>
> Uncrustify might support this now, but I have never seen even a single IDE
> that does.
88 matches
Mail list logo
