On macOS, /usr/bin/gcc is clang, and so doesn't have
the -Wno-error=stringop-overflow flag that was added
for gcc 12.
Update the GNUmakefile for DevicePath to skip setting
that on macOS.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
This reverts commit d5fd86f256 for tag202208.
This feature will be merged after stable tag 202208 is created.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Update package maintainers for below package/arch,
1. RISCV64 Architecture:
Abner is stepping out from RISC-V stuff for now and hand over edk2 RISC-V
responsibilities to Sunil.
Daniel Schaefer is no longer with HPE. Update his email address for
RISCV64 arch. He will keep helping on RISC-V stuff with his personal
email.
2. EmbeddedPkg:
Daniel Schaefer is no longer with HPE. Update his email address for
EmbeddedPkg.
3. EmulatorPkg and RedfishPkg:
Nickle Wang is no longer with HPE. Update his email address for
EmulatorPkg and RedfishPkg packages. He will use the personal email for
the time being until he gets ready with his next journey.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Nickle Wang <nickle@csie.io>
Reviewed-by: Daniel Schaefer <git@danielschaefer.me>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Nickle Wang <nickle@csie.io>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Bugzilla: 3995 (https://bugzilla.tianocore.org/show_bug.cgi?id=3995)
ACPI 6.4 spec states that if the revision field in the DSDT header is less
than 2, then all integers are restricted in width to 32 bits, including in
SSDTs.
Arm Base boot requirements state that platforms must conform to ACPI 6.3
or later, and that legacy tables are not supported.
Adds a check for this field and raise warning if revision is less
than 2 on arm.
Signed-off-by: Edward Pickup <edward.pickup@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
There is no function to send POST request with the
ContentType different from "application\json".
There is no function to send DELETE request with the body.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Definitions of the required functions to send requests to BMC
are in the PrivateInclude folder. So they cannot be used by
the other Redfish packages.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Host Interface details are described by the SMBIOS Type 42
table. The table is published by the RedfishHostInterfaceDxe
driver. That driver supports PCI-E and USB host interface
types.The table is consumed by the edfishGetHostInterfaceProtocolData
function in the RedfishDiscoverDxe driver. The function only supports
PCI-E host interface type.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Since PeerGroups has a variable number of entries, new fields added
after PeerGroups are defined in a extended structure.
Done changes in PrintInfo.c to access those fields using
SMBIOS_TABLE_TYPE9_EXTENDED structure from SmBios.h.
Signed-off-by: Sainadh Nagolu <sainadhn@ami.com>
Cc: Vasudevan Sambandan <vasudevans@ami.com>
Cc: Sundaresan S <sundaresans@ami.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In Type9 structure since PeerGroups has a variable
number of entries, must not define new fields in the structure.So added an
extended structure and defined new fields added after PeerGroups. Also done
some improvements to Smbios 3.5.0 spec changes.
Signed-off-by: Sainadh Nagolu <sainadhn@ami.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Some print statements use format specifiers like %N/%H/%E/%B that are
only supported in the shell print functions. In the ordinary 'Print'
function they are just displayed as letters N/H/E/B.
Remove these unsupported format specifiers from the 'Print' statements
to fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The current implementation does not check if Language or DriverName
are NULL. This causes the SCT test suite to crash.
Add a check to return EFI_INVALID_PARAMETER if any of these pointers
are NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
The current implementation does not check if Info or SizeInfo
pointers are NULL. This causes the SCT test suite to crash.
Add a check to return EFI_INVALID_PARAMETER if any of these
pointers are NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
The current implementation does not check if Progress or Results
pointers in ExtractConfig are NULL, or if Progress pointer in
RouteConfig is NULL. This causes the SCT test suite to crash.
Add a check to return EFI_INVALID_PARAMETER if any of these pointers
are NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Add host based unit tests for the CpuPageTableLib services.
Unit test focuses on PageTableMap function, containing two kinds of test
cases: manual test case and random test case.
Manual test case creates some corner case to test function PageTableMap.
Random test case generates multiple random memory entries (with random
attribute) as the input of function PageTableMap to get the output
pagetable. Output pagetable will be validated and be parsed to get output
memory entries, and then the input and output memory entries will be
compared to verify the functionality.
The unit test is not perfect yet. There are options for random test, and
some of them control the test coverage, and some option are not ready.
Will enhance in the future.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Remove clearing CR0.WP when marking the memory used for page table
as read-only in the page table itself created by UefiPayloadEntry.
This page table address is written to Cr3 after these protection
steps. Till this, the memory used for page table is always RW.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Remove clearing CR0.WP when marking the memory used for page table
as read-only in the page table itself created by DxeIpl. This page
table address is written to Cr3 after these protection steps. Till
this, the memory used for page table is always RW.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This patch is code refactoring and doesn't change any functionality.
Remove mInternalCr3 in PiSmmCpuDxe pagetable related code. In previous
code, mInternalCr3 is used to pass address of page table which is
different from Cr3 register in different level of SetMemoryAttributes
function. Now remove it and pass the page table base address from the
root function parameter to simplify the code logic.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This patch is code refactoring and doesn't change any functionality.
Add a new mIsShadowStack flag to identify whether current memory is
shadow stack. Previous smm code logic regards a RO range as shadow
stack and set the dirty bit in corresponding page table entry if
mInternalCr3 is not 0, which may be confusing.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=4000
Change flow to bus scan all root bridge instances even when any
one root bridge meet bus resource OUT_OF_RESOURCE case.
thus platform handler of "EfiPciHostBridgeEndBusAllocation" has
an chance to do relative pci bus rebalance to handle this case.
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
With following paging structure to map
[2M-4K, 2M] as P = 1, RW = 0,
[2M, 4M] as P = 1, RW = 1:
PML4[0] -> PDPTE[0] -> PDE[0](RW = 0) -> PTE[255](P = 0, RW = 0)
-> PDE[1](RW = 1)
When a new request to map [2M-4K, 2M+4K] as P = 1, RW = 1,
CpuPageTableMap() wrongly requests 4K buffer size for the new mapping
request.
But in fact, for [2M-4K, 2M] request, PTE[255] can be changed in place,
for [2M, 2M+4K], no change is needed because PDE[1].RW = 1 already.
The change fixes the bug.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
With the following paging structure that maps [0, 2G] with ReadWrite
bit set.
PML4[0] --> PDPTE[0] --> PDE[0-255]
\-> PDPTE[1] --> PDE[0-255]
If ReadWrite bit is cleared in PML4[0] and PageTableMap() is called
to change [0, 2M] as read-only, today's logic unnecessarily changes
the paging structure in 2 aspects:
1. When setting PageTableBaseAddress in the entry, the code clears
all attributes.
2. Even the ReadWrite bit in parent entry is not set, the code clears
the ReadWrite bit in the leaf entry.
First change is wrong. It should not change other attributes when
setting the PA.
Second change is unnecessary. Because the parent entry already
declares the whole region as read-only, there is no need to clear
ReadWrite bit in the leaf entry again.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
With the following paging structure that maps [0, 2G] with ReadWrite
bit set.
PML4[0] --> PDPTE[0] --> PDE[0-255]
\-> PDPTE[1] --> PDE[0-255]
If ReadWrite bit is cleared in PML4[0] and PageTableMap() is called
to change [0, 2M] as writable, today's logic doesn't inherit the
parent entry's attributes when determining the child entry's
attributes. It just sets the PDPTE[0].PDE[0].ReadWrite bit.
But since the PML4[0].ReadWrite is 0, [0, 2M] is still read-only.
The change fixes the bug.
If the inheritable attributes in ParentPagingEntry conflicts with the
requested attributes, let the child entries take the parent attributes
and loosen the attribute in the parent entry.
E.g.: when PDPTE[0].ReadWrite = 0 but caller wants to map [0-2MB as
ReadWrite = 1 (PDE[0].ReadWrite = 1), we need to change
PDPTE[0].ReadWrite = 1 and let all PDE[0-255].ReadWrite = 0 first.
Then change PDE[0].ReadWrite = 1.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Today's logic wrongly treats the non-leaf entry as leaf entry and
updates its paging attributes.
The patch fixes the bug to only update paging attributes for
non-present entries or leaf entries.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
When PageTableMap() is called to create non 1:1 mapping
such as [0, 1G) to [8K, 1G+8K), it should split the page entry to the
4K page level, but old logic has a bug that it just uses 1G page
entry.
The patch fixes the bug.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
The patch replaces
LinearAddress + Offset == RegionStart
with
((LinearAddress + Offset) & RegionMask) == 0
The replace should not cause any behavior change.
Because:
1. In first loop of while when LinearAddress + Offset == RegionStart,
because the lower "BitStart" bits of RegionStart are all-zero,
all lower "BitStart" bits of (LinearAddress + Offset) are all-zero.
Because all lower "BitStart" bits of RegionMask is all-one and
bits are all-zero, ((LinearAddress + Offset) & RegionMask) == 0.
2. In following loops of the while, even RegionStart is increased
by RegionLength, the lower "BitStart" bits are still all-zero.
So the two expressions still semantically equal to each other.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
When LinearAddress or Length is not aligned on 4KB, PageTableMap()
should return Invalid Parameter.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
The lib includes two APIs:
* PageTableMap
It creates/updates mapping from LA to PA.
The implementation only supports paging structures used in 64bit
mode now. PAE paging structure support will be added in future.
* PageTableParse
It parses the page table and returns the mapping relations in an
array of IA32_MAP_ENTRY.
It passed some stress tests. These test code will be upstreamed in
other patches following edk2 Unit Test framework.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
CPU_EXCEPTION_INIT_DATA is now an internal implementation of
CpuExceptionHandlerLib. Union can be removed since Ia32 and X64 have the
same definition. Also, two fields (Revision and InitDefaultHandlers)are
useless, can be removed.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Specify how to build the PrmPkg for the AArch64 architecture.
Make the 2 following notes:
- the PrmPkg has only been tested on AArch64 using the GCC5
toolchain.
- All symbols to be listed in the PRMT as well as the
PrmModuleExportDescriptor must be explicitly preserved by resorting to
the --require-defined linker flag.
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add support to build PrmPkg for AArch64 using the GCC compiler.
Add AARCH64 architecture to the list of supported architectures.
Add BaseStackCheck library to allow for Prm module builds on AARCH64.
Also update the CI to add dependency on ArmPkg.
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
- Add the --prm flag to the GENFW_FLAGS
- Add the --no-gc-section to the linker flags so that apparently
unreferenced symbols are not prematurely removed from the .dll which
is used to generate the Prm module .efi.
- Force the linker to maintain the PrmModuleExportDescriptor symbol.
- Force the linker to maintain the PRM handler funtion's symbol.
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The GenFw invocation with the --prm flag was previously reserved for
X64.
AArch64 platforms, built with GCC5, can also deploy PRM modules, hence
the --prm flag is also applicable in builds targeting the AARCH64
architecture.
This commit enables the --prm flag to be used for EDK2 builds targeting
AARCH64.
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION
structure.
This value describes the raw data inside the section.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng<bob.c.feng@intel.com>
Currently there is no labels for start and end of the
EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not
possible to see where the FV section ends and another section starts.
Add labels for start and end of the FV sections to fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add
an additional check for ACPI version. This fixes a crash running on
kvmtool.
Signed-off-by: Edward Pickup <edward.pickup@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Ensure that the PixelInformation field of the
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is zeroed out in
EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() and
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() when PixelFormat is
PixelBlueGreenRedReserved8BitPerColor.
According to UEFI 2.9 Section 12.9, PixelInformation field of the
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is valid only if
PixelFormat is PixelBitMask. This means that firmware is not required
to fill out the PixelInformation field for other PixelFormat types,
which implies that the QemuVideoDxe implementation is technically
correct.
However, not zeroing out those fields will leak the contents of the
memory returned by the memory allocator, so it is better to explicitly
set them to zero.
In addition, the SCT test suite relies on PixelInformation always
having a consistent value, which causes failures.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Bugzilla: 3458 - Add support IORT Rev E.d specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.d,
Feb 2022 (https://developer.arm.com/documentation/den0049/)
introduces the following updates, collectively including the
updates and errata fixes to Rev E, Rev E.a, Rev E.b, Rev E.c:
- increments the IORT table revision to 5.
- updates the node definition to add an 'Identifier' field.
- adds definition of node type 6 - Reserved Memory Range node.
- adds definition for Memory Range Descriptors.
- adds flag to indicate PRI support for root complexes.
- adds flag to indicate if the root complex supports forwarding
of PASID information on translated transactions to the SMMU.
- adds flag to indicate if the root complex supports PASID.
- adds flags to define access privilege and attributes for the
memory ranges.
Therefore, update the IORT generator to:
- increment IORT table revision count to 5.
- populate Identifier filed if revision is greater than 4.
- add support to populate Reserved Memory Range nodes and
the Memory range descriptors.
- add validation to check that the Identifier field is
unique.
- Populate the PASID capabilities and Flags field of the
Root complex node.
- Added checks to not generate IORT Rev E, Rev E.<a,b,c>.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Bugzilla: 3458 - Add support IORT Rev E.d specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.d,
Feb 2022 (https://developer.arm.com/documentation/den0049/)
introduces the following updates, collectively including the
updates and errata fixes to Rev E, Rev E.a, Rev E.b, Rev E.c:
- increments the IORT table revision to 5.
- updates the node definition to add an 'Identifier' field.
- adds definition of node type 6 - Reserved Memory Range node.
- adds definition for Memory Range Descriptors.
- adds flag to indicate PRI support for root complexes.
- adds flag to indicate if the root complex supports forwarding
of PASID information on translated transactions to the SMMU.
- adds flag to indicate if the root complex supports PASID.
- adds flags to define access privilege and attributes for the
memory ranges.
Therefore, update the Arm namespace objects to:
- add Identifier field to IORT nodes.
- introduce enums to represent RMR nodes and Memory Range
descriptors.
- add definition of node type 6 - Reserved Memory Range node.
- add definition for Memory Range Descriptors.
- add PASID capabilities and flags field to Root Complex node.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Bugzilla: 3458 - Add support IORT Rev E.d specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.d,
Feb 2022 (https://developer.arm.com/documentation/den0049/)
introduces the following updates, collectively including the
updates and errata fixes to Rev E, Rev E.a, Rev E.b, Rev E.c:
- increments the IORT table revision to 5.
- updates the node definition to add an 'Identifier' field.
- adds definition of node type 6 - Reserved Memory Range node.
- adds definition for Memory Range Descriptors.
- adds flag to indicate PRI support for root complexes.
- adds flag to indicate if the root complex supports forwarding
of PASID information on translated transactions to the SMMU.
- adds flag to indicate if the root complex supports PASID.
- adds flags to define access privilege and attributes for the
memory ranges.
Therefore, update the IORT parser to:
- parse the Identifier field.
- parse Reserved Memory Range node.
- parse Memory Range Descriptors.
- add validations to check that the physical range base
and size of the Memory Range Descriptor is 64KB aligned.
- add validation to check that the IORT Table Revision is
not 4 as IORT Rev E.c is deprecated.
- add validation to check that the IORT RMR node revision
is not 2 as it breaks backward compatibility and was
deprecated as part of IORT Rev E.c.
- skip parsing of IORT Rev E, Rev E.a, Rev E.b, Rev E.c as
some fields were deprecated in these revisions.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Bugzilla: 3458 - Add support IORT Rev E.d specification updates
(https://bugzilla.tianocore.org/show_bug.cgi?id=3458)
The IO Remapping Table, Platform Design Document, Revision E.d,
Feb 2022 (https://developer.arm.com/documentation/den0049/)
introduces the following updates, collectively including the
updates and errata fixes to Rev E, Rev E.a, Rev E.b, Rev E.c:
- increments the IORT table revision to 5.
- updates the node definition to add an 'Identifier' field.
- adds definition of node type 6 - Reserved Memory Range node.
- adds definition for Memory Range Descriptors.
- adds flag to indicate PRI support for root complexes.
- adds flag to indicate if the root complex supports forwarding
of PASID information on translated transactions to the SMMU.
- adds flag to indicate if the root complex supports PASID.
- adds flags to define access privilege and attributes for the
memory ranges.
Therefore, update the IORT header file to reflect these changes,
and also rename the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro to
EFI_ACPI_IO_REMAPPING_TABLE_REVISION_00.
Also update the IORT generator in DynamicTablesPkg to fix the
compilation errors so that Git Bisect can work.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
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 <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
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 Mapping count is zero rather than populating it with an incorrect
value.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Add error handling when the IdMappingCount is not zero and the
IdMappingToken is NULL.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
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 <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Writes TianoCore debug logs into the CBMEM console ringbuffer, from
where the user can retrieve them with the `cbmem` userspace utility.
The intention is to aid in debugging non-fatal issues even in release
builds, or simply make TianoCore's logs available to those interested.
Consequently, MDEPKG_NDEBUG must be masked. As an in-memory debug
logging library, ASSERTs must be non-fatal to be seen, so they neither
dead-loop nor create a breakpoint. It is assumed that ASSERT() neither
enforces fatal conditions nor security integrity, as release builds do
not call DebugAssert() from the ASSERT macro.
More detailed debug logs are produced with the DEBUG_CODE macro, but
this guards other debug-related code throughout the codebase. To avoid
changing behaviour on release builds, this is only set for debug builds.
Tested on QEMU, dumping the appropriate memory region in the UEFI shell
shows the TianoCore log. An improved revision of the debug library used
in several coreboot-related EDK2 forks, including MrChromebox's.
Previous revisions also tested on an Acer Aspire VN7-572G laptop.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Currently there is no labels for start and end of the encapsulation
sections. Therefore it is not possible to see where the encapsulation
section ends and another section starts.
Add labels for start and end of encapsulation sections to fix the
issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently, "push byte %[Vector]" causes nasm warning when Vector is larger
than 0x7F. This is because push accepts a signed value, and byte means
signed int8. Maximum signed int8 is 0x7F.
When Vector is larger the 0x7F, for example, when Vector is 255, byte 255
turns to -1, and causes the warning "signed byte value exceeds".
To avoid such warning, use dword instead of byte, this will increase 3 bytes
for each IdtVector.
For IA32, the size of IdtVector will increase from 10 bytes to 13 bytes.
For X64, the size of IdtVector will increase from 15 bytes to 18 bytes.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Harry Han <harry.han@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
- Correct typo in print statement,
- "BuildNumber" field is UINT16, therefore it needs "0x%04X" format
modifier,
- "VersionString" field is CHAR16, therefore the input data should be
processed to be displayed with "%s" printf modifier.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently sections with unknown types are displayed as
`EFI_SECTION_SMM_DEPEX` which is wrong.
Increase the highest value for the section type to 0x1C
for correct parsing.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Alignment attribute is not a bitmask, therefore we need to compare
field value with all alignment defines.
Remove duplicate print statements. Unify indent with other attribute
print statements.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch is a bug fix about FeatureFlagExpression in INF file:
INF [Source] section now unconditionally use Pcd default value in DEC
when handling FeatureFlagExpression, it is wrong.
If a Pcd value has been set in the DSC file, we should use latest
value in DSC instead of default value.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yi Li <yi1.li@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3986
The EFI_STATUS_CODE_DATA_MAX_SIZE is defined as 200 in MdeModulePkg.
After reducing 96byte buffer for variable parameters it is limited to
only 104 char debug string. This is a non-necessary limitation.
This change sets EFI_STATUS_CODE_DATA_MAX_SIZE to 0x200, and moves
MAX_EXTENDED_DATA_SIZE definition to the same header file with value
of EFI_STATUS_CODE_DATA_MAX_SIZE + sizeof (EFI_STATUS_CODE_DATA)
which is used in ReportStatusCodeLib to support longer debug string.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Cosmo Lai <cosmo.lai@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
The ARM_PROCESSOR_TABLE pseudo-ACPI table (which carries a ACPI-table
like header but is published as a EFI config table) is not described in
any relevant spec, and is not known to be relied upon by any OS. Let's
just get rid of it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3952
In UEFI spec, it defines reconnect timing that will be activated upon
exiting of the formset or the browser. However, we did't use this kind
of way to check reconnect conditioncode. Code only blocks reconnect if
page is updated dynamically. That's not matched spec'd way. We should
check current formset whether is exiting, then reconnect driver.
Signed-off-by: Walon Li <walon.li@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add support library to allow for customization of _OSC and slot info.
The functions in the library are unchanged,
with the exception of adding PciInfo pointer to the APIs.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add support for PCIe devices with UID > 0xF.
This is done by using the next value in the name so
PCI5, PC26, etc
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
SSDT tables describing an SBSA compatible serial port receive an '_HID'
value of 'ARMH0011'. This value represents a PL011 serial port.
This patch:
- Generates an 'ARMHB000' instead
- References the 'ACPI for Arm Components 1.0 - 2020' document
specifying the '_HID' values to use.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Device Tree PCI interrupt flags use the convention described at
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered (invalid for SPIs)
4 = active high level-sensitive
8 = active low level-sensitive (invalid for SPIs).
Fix the incorrect code.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Currently BaseTools use 'cp' command for PcdValueInit and GenMake
process, as the command can not keep the time info of the source
file, which will cause incremental build issue in Linux system,
thus the '-p' need be added to keep the source file's attributes
in copy process.
This patch fixes this issue.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The CM_STD_OBJ_ACPI_TABLE_INFO.AcpiTableRevision can be used to specify
the major revision number of the ACPI table that the generator must use.
Although most ACPI tables only have a major revision number, the FADT
table additionally has a minor revision number.
The FADT generator currently defaults to setting the latest supported
ACPI revision for the FADT table i.e. ACPI 6.4. This means that the minor
revision for the FADT table is always set to 4 and there is no provision
for a user to specify the minor revision to be selected.
Therefore, update CM_STD_OBJ_ACPI_TABLE_INFO to introduce a new field
MinorRevision which can be used to specify the minor revision for an
ACPI table. Also update the FADT generator to validate the supported
FADT revisions ans use the specified minor revision for the FADT table
if supported. If an unsupported minor revision is specified the FADT
generator defaults to the latest supported minor revision.
Since the CM_STD_OBJ_ACPI_TABLE_INFO.MinorRevision field is added to
the end of the structure, it should not break existing platform code.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: <pierre.gondois@arm.com>
Tested-by: Jagadeesh Ujja <Jagadeesh.Ujja@arm.com>
Updated DMAR definitions accordingly to changes in Intel(R) Virtualization
Technology for Directed I/O (VT-D) Architecture Specification ver4.0.
Added new definition of remapping structure - SIDP. The SoC Integrated
Device Property (SIDP) reporting structure identifies devices that have
special properties and that may put restrictions on how system software
must configure remapping structures that govern such devices in a platform
where remapping hardware is enabled.
Updated DRHD definition - field 'reserved' is replaced with 'Size'.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3978
Signed-off-by: Robert Kowalewski <robert.kowalewski@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Jenny Huang <jenny.huang@intel.com>
Cc: Sheng Wei <w.sheng@intel.com>
Reviewed-by: Sheng Wei <w.sheng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The python BaseTools/Edk2ToolsBuild.py creates files in
BaseTools/BaseToolsBuild and should be ignored.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
There are two scene communicate with StandaloneMm(MM):
1 edk2 -> TF-A -> MM, communicate MM use non-secure buffer which
specify by EFI_SECURE_PARTITION_BOOT_INFO.SpNsCommBufBase;
2 RAS scene: fiq -> TF-A -> MM, use secure buffer which
specify by EFI_SECURE_PARTITION_BOOT_INFO.SpShareBufBase;
For now, the second scene will failed because check buffer address.
This patch add CheckBufferAddr() to support check address for secure
buffer.
Signed-off-by: Ming Huang <huangming@linux.alibaba.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
TF-A: TrustedFirmware-A
SPM: Secure Partition Manager(MM)
In TF-A, the name of this field is sp_shared_buf_size. This field is
the size of range for transmit data from TF-A to standaloneMM when
SPM enable.
SpPcpuSharedBufSize is pass from TF-A while StandaloneMM initialize.
So, SpPcpuSharedBufSize should be rename to SpSharedBufSize and this field
should no multiply by PayloadBootInfo->NumCpus;
Signed-off-by: Ming Huang <huangming@linux.alibaba.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The issue appears to have been introduced by:
41fb5d46 : ArmPkg/ArmGic: Use the GIC Redistributor instead of GIC Distributor for GICv3
The changes to ArmGicIsInterruptEnabled() introduced the error where the Boolean
result is assigned to Interrupts, but then the bit position check is performed
again (against the computed Boolean result instead of the interrupt mask) during
the return statement.
Fix removes erroneous test and relies on boolean test made at return.
Signed-off-by: Robbie King <robbiek@xsightlabs.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Upgrade the edk2-basetools version from 0.1.17 to 0.1.24
features and bug fixes:
1. Add FMMT Python Tool
2. Remove RVCT support
3. Fix dependency issue in PcdValueInit
4. Output the intermediate library instance when error occurs
5. Ecc: Fix grammar in Ecc error message
6. Fix the GenMake bug for .cpp source file
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Add support process Port Speed field value of PORTSC according to
Supported Protocol Capability (define in xHCI spec 1.1)
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3914
The value of Port Speed field in PORTSC bit[10:13]
(xHCI spec 1.1 section 5.4.8) should be change to use this value to
query thru Protocol Speed ID (PSI) (xHCI spec 1.1 section 7.2.1)
in xHCI Supported Protocol Capability and return the value according
the Protocol Speed ID (PSIV) Dword.
With this mechanism may able to detect more kind of Protocol Speed
in USB3 and also compatiable with three kind of speed of USB2.
Cc: Jenny Huang <jenny.huang@intel.com>
Cc: More Shih <more.shih@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ian Chiu <Ian.chiu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Include HardwareInfoLib classes in the IntelTdxX64.dsc for this
platform to use it during build given that PciHostBridgeUtilityLib
depends on it.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Include DxeHardwareInfoLib class in the common ArmVirt.dsc.inc so that
ArmVirt* platforms use it during build given that PciHostBridgeUtilityLib
depends on it.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
A memory range can be submitted for attribute changes which is large
enough to not require a page split during the attribute update. Consider
the following scenario:
1. An attribute update removed the RW attribute on a range large enough
to not require a page split.
2. Later, an attributes update is called to re-add the RW attribute for
a subsection of that larger page which requires a split
3. The attribute update logic performs a page split, so now the parent
and child pages have matching attributes
4. Then, the attribute update logic changes the child page to have the
RW attribute.
5. The child page would then correctly have the RW attribute added but
the parent page would still have the RW attribute removed which will
cause an improper access violation.
The page being split should have loose attributes to accommodate the
above case. The split page should always have the attributes set so
the lowest level page frame determines the access rights as detailed
in 4.10.2.2 of the Intel 64 and IA-32 Architectures Software
Developer Manual. Setting the User/Supervisor attribute shouldn't
be necessary.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
For Arm platforms that support more that one serial port, one of the
serial port can be used for connecting debuggers such as WinDbg. There
are PCDs that allow the base address and clock rate to be specified for
this debug serial port but not its interrupt number. So add a PCD to
specify the interrupt number assigned to the serial debug port
controller.
Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate size of physical addresses.
Using the static PeiHardwareInfoLib, read the fw-cfg file of
hardware information to extract, one by one, all the host
bridges. Find the last 64-bit MMIO address of each host bridge,
using the HardwareInfoPciHostBridgeLib API, and compare it to an
accumulate value to discover the highest address used, which
corresponds to the highest value that must be included in the
guest's physical address space.
Given that platforms with multiple host bridges may provide the PCI
apertures' addresses, the memory detection logic must take into
account that, if the host provided the MMIO windows that can and must
be used, the guest needs to take those values. Therefore, if the
MMIO windows are found in the host-provided fw-cfg file, skip all the
logic calculating the physical address size and just use the value
provided. Since each PCI host bridge corresponds to an element in
the information provided by the host, each of these must be analyzed
looking for the highest address used.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Following the Hardware Info library, create the DxeHardwareInfoLib
which implements the whole API capable of parsing heterogeneous hardware
information. The list-like API grants callers a flexible and common
pattern to retrieve the data. Moreover, the initial source is a BLOB
which generalizes the host-to-guest transmission mechanism.
The Hardware Info library main objective is to provide a way to
describe non-discoverable hardware so that the host can share the
available resources with the guest in Ovmf platforms. This change
features and embraces the main idea behind the library by providing
an API that parses a BLOB into a linked list to retrieve hardware
data from any source. Additionally, list-like APIs are provided so
that the hardware info list can be traversed conveniently.
Similarly, the capability is provided to filter results by specific
hardware types. However, heterogeneous elements can be added to the
list, increasing the flexibility. This way, a single source, for
example a fw-cfg file, can be used to describe several instances of
multiple types of hardware.
This part of the Hardware Info library makes use of dynamic memory
and is intended for stages in which memory services are available.
A motivation example is the PciHostBridgeLib. This library, part
of the PCI driver populates the list of PCI root bridges during DXE
stage for future steps to discover the resources under them. The
hardware info library can be used to obtain the detailed description
of available host bridges, for instance in the form of a fw-cfg file,
and parse that information into a dynmaic list that allows, first to
verify consistency of the data, and second discover the resources
availabe for each root bridge.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is provided.
The Hardware Info library is intended to describe non-discoverable
hardware information and share that from the host to the guest in Ovmf
platforms. The QEMU fw-cfg extension for this library provides a first
variation to parse hardware info by reading it directly from a fw-cfg
file. This library offers a wrapper function to the plain
QmeuFwCfgReadBytes which, specifically, parses header-data pairs out
of the binary values in the file. For this purpose, the approach is
incremental, reading the file block by block and outputting the values
only for a specific known hardware type (e.g. PCI host bridges). One
element is returned in each call until the end of the file is reached.
Considering fw-cfg as the first means to transport hardware info from
the host to the guest, this wrapping library offers the possibility
to statically, and in steps, read a specific type of hardware info
elements out of the file. This method reads one hardware element of a
specific type at a time, without the need to pre-allocate memory and
read the whole file or dynamically allocate memory for each new
element found.
As a usage example, the static approach followed by this library
enables early UEFI stages to use and read hardware information
supplied by the host. For instance, in early times of the PEI stage,
hardware information can be parsed out from a fw-cfg file prescinding
from memory services, that may not yet be available, and avoiding
dynamic memory allocations.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Create the Hardware Info library base together with the specifics to
describe PCI Host Bridges.
The Hardware Info library is intended to be used for disclosing
non-discoverable hardware information from the host to the guest in
Ovmf platforms. Core functionality will provide the possibility to
parse information from a generic BLOB into runtime structures. The
library is conceived in a generic way so that further hardware
elements can also be described using it. For such purpose the length
of the BLOB is not restricted but instead regarded as a sequence of
header-info elements that allow the parsing during runtime. The first
type of hardware defined will be PCI host bridges, providing the
possibility to define multiple and specify the resources each of them
can use. This enables the guest firmware to configure PCI resources
properly. Having the size of each individual element favors the reuse
of a single interface to convey descriptions of an arbitrary number
of heterogenous hardware elements. Furthermore, flexible access
mechanisms coupled with the size will grant the possibility of
interpreting them in a single run.
Define the base types of the generic Hardware Info library to parse
heterogeneous data. Also provide the specific changes to support
PCI host bridges as the first hardware type supported by the
library.
Additionally, define the HOST_BRIDGE_INFO structure to describe PCI
host bridges along with the functionality to parse such information
into proper structures used by the PCI driver in a centralized manner
and taking care of versioning.
As an example and motivation, the library will be used to define
multiple PCI host bridges for complex platforms that require it.
The first means of transportation that will be used is going to be
fw-cfg, over which a stream of bytes will be transferred and later
parsed by the hardware info library. Accordingly, the PCI driver
will make use of these host bridges definitions to populate the
list of Root Bridges and proceed with the configuration and discovery
of underlying hardware components.
As mentioned before, the binary data to be parsed by the Hardware
Info library should be organized as a sequence of Header-element
pairs in which the header describes the type and size of the associated
element that comes right after it. As an illustration, to provide
inforation of 3 host bridges the data, conceptually, would look
like this:
Header PCI Host Bridge (type and size) # 1
PCI Host Bridge info # 1
Header PCI Host Bridge (type and size) # 2
PCI Host Bridge info # 2
Header PCI Host Bridge (type and size) # 3
PCI Host Bridge info # 3
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
We can have multiple [LibraryClasses] sections, so we can place
all TPM-related library configuration to a single include file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The DEBUG output in LcdGraphicsBlt is overly verbose, and makes using
the console difficult, for example when using the UiApp.
Since the extra output should no longer be needed, delete the DEBUG
lines.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
We observed page fault in the following situation:
1.PayloadEntry uses 2M entry in page table to cover DXE stack range.
2.In DXE phase, image protection code needs to mark some sub-range in
this 2M entry as readonly. So the the 2M page table entry is split to
512 4K entries, and some of the entries are marked as readonly.
(the entries covering stack still remain R/W)
3.Page fault exception happens when trying to access stack.
Always split the page table entry to 4K if it covers stack to avoid this
issue.
More discussion about this issue can be seen at below link
https://edk2.groups.io/g/devel/topic/91446026
Cc: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The maximum Unicode string could be as large as 1800000 in certain
platforms when HII code builds the configuration strings.
This causes assertion in PrintLib.
The patch increases the PcdMaximumUnicodeStringLength to 1800000 to
avoid the assertion.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
When a module "Module" depends on a library instance "Lib1" which
depends on "Lib2" which depends on "Lib3" ... depends on "LibN",
but "LibN" doesn't support the type (e.g.: SEC) of the "Module", the
following error messages are printed by build tool:
<DSC path>(...): error 1001: Module by library instance [<LibN path>]
consumed by [<Module path>]
But it's unclear to user how LibN is consumed by the Module.
With the patch, following errors are printed:
<DSC path>(...): error 1001: Module by library instance [<LibN path>]
consumed by library instance [<Lib N-1 path>] which is
consumed by module[<Module path>]
It doesn't print all the intermediate library instances between the
Module and LibN but at least the path of Lib N-1 can help users
to help how to fix the build errors.
I hope this patch can be a trigger point that a better solution could
be developed by tool experts to print all the library instances
between the Module and LibN.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.fen@intel.com>
Commit e7abb94d1 removed InitializeCpuExceptionHandlersEx
and updated DxeMain to call InitializeCpuExceptionHandlers
for exception setup. But the old behavior that calls *Ex() sets
up the stack guard as well. To match the old behavior,
the patch calls InitializeSeparateExceptionStacks.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
CpuExceptionHandlerLib has been refactored with following changes:
1. Removed InitializeCpuInterruptHandlers in 2a09527ebc
2. Removed InitializeCpuExceptionHandlersEx and
added InitializeSeparateExceptionStacks in e7abb94d1f
The patch updates ARM version of CpuExceptionHandlerLib to follow
the API changes.
The functionality to ARM platforms should be none.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This reverts commit ff36b2550f.
Has no effect because GCC_IA32_CC_FLAGS and GCC_X64_CC_FLAGS are unused.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The AP vector consists of 2 parts:
1. the initial 16-bit code that should be under 1MB and page aligned.
2. the 32-bit/64-bit code that can be anywhere in the memory with any
alignment.
The need of part #2 is because the memory under 1MB is temporary
"stolen" for use and will "give" back after all AP wake up. The range
of memory is not marked as code page in page table. CPU may trigger
exception as soon as NX is enabled.
The part #2 memory allocation can be done in the MpInitLibInitialize.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Today's implementation allocates below 1MB memory for the 16bit, 32bit
and 64bit code.
But it's not necessary since now the 32bit and 64bit code run at high
memory no matter in PEI and DXE phase.
The patch simplifies the logic to remove the code that handles the
case when WakeupBufferHigh is 0.
It also reduce the memory foot print under 1MB by allocating
memory for 16bit code only.
MP_CPU_EXCHANGE_INFO is still under 1MB which is immediate
after the 16bit code.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
global in NASM file is used for symbols that are
referenced in C files.
Remove unneeded global keyword in NASM file.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Today's implementation assumes PEI phase runs at 32bit so
the execution-disable feature is not applicable.
It's not always TRUE.
The patch allocates 32bit&64bit code buffer for PEI phase as well.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Today InitializeCpuExceptionHandlersEx is called from three modules:
1. DxeCore (links to DxeCpuExceptionHandlerLib)
DxeCore expects it initializes the IDT entries as well as
assigning separate stacks for #DF and #PF.
2. CpuMpPei (links to PeiCpuExceptionHandlerLib)
and CpuDxe (links to DxeCpuExceptionHandlerLib)
It's called for each thread for only assigning separate stacks for
#DF and #PF. The IDT entries initialization is skipped because
caller sets InitData->X64.InitDefaultHandlers to FALSE.
Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib
also implement such API and the behavior of the API is simply to initialize
IDT entries only.
Because it mixes the IDT entries initialization and separate stacks
assignment for certain exception handlers together, in order to know
whether the function call only initializes IDT entries, or assigns stacks,
we need to check:
1. value of InitData->X64.InitDefaultHandlers
2. library instance
This patch cleans up the code to separate the stack assignment to a new API:
InitializeSeparateExceptionStacks().
Only when caller calls the new API, the separate stacks are assigned.
With this change, the SecPei and Smm instance can return unsupported which
gives caller a very clear status.
The old API InitializeCpuExceptionHandlersEx() is removed in this patch.
Because no platform module is consuming the old API, the impact is none.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
InitializeCpuExceptionHandlers() expects caller allocates IDT while
InitializeCpuInterruptHandlers() allocates 256 IDT entries itself.
InitializeCpuExceptionHandlers() fills max 32 IDT entries allocated
by caller. If caller allocates 10 entries, the API just fills 10 IDT
entries.
The inconsistency between the two APIs makes code hard to
unerstand and hard to share.
Because there is only one caller (CpuDxe) for
InitializeCpuInterruptHandler(), this patch updates CpuDxe driver
to allocates 256 IDT entries then call
InitializeCpuExceptionHandlers().
This is also a backward compatible change.
With this change, InitializeCpuInterruptHandlers() is removed
completely.
And InitializeCpuExceptionHandlers() fills max 32 entries for PEI
and SMM instance, max 256 entries for DXE instance.
Such behavior matches to the original one.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Additionally removed two useless global variables:
"SPIN_LOCK mDisplayMessageSpinLock" from SMM instance.
"UINTN mEnabledInterruptNum" from DXE instance.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Today the DXE instance allocates code page and then copies the IDT
vectors to the allocated code page. Then it fixes up the vector number
in the IDT vector.
But if we update the NASM file to generate 256 IDT vectors, there is
no need to do the copy and fix-up.
A side effect is 4096 bytes (HOOKAFTER_STUB_SIZE * 256) is used for
256 IDT vectors while 32 IDT vectors only require 512 bytes without
this change, in following library instances:
1. 32bit SecPeiCpuExceptionHandlerLib and PeiCpuExceptionHandlerLib
2. 64bit PeiCpuExceptionHandlerLib
But considering the code logic simplification, 3.5K extra space is
not a big deal.
If 3.5K is too much, we can enhance the code further to generate 32
vectors for above mentioned library instances.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Acked-by: Eric Dong <eric.dong@intel.com>
The ebp/rbp register can either be used for the frame pointer or
as general purpose register. With gcc (and clang) this depends
on the -f(no-)omit-frame-pointer switch.
This patch updates tools_def.template to explicitly set the compiler
option and also add a define to allow conditionally compile code.
The new define is used to fix stack switching in TemporaryRamMigration.
The ebp/rbp must not be touched when the compiler can use it as general
purpose register. With version 12 gcc starts actually using the
register, so changing it leads to firmware crashes in some
configurations.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3934
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The feature of SecMeasurementLibTdx is replaced by SecTpmMeasurementLibTdx
(which is in SecurityPkg). So SecMeasurementLibTdx is deleted.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
MeasureHobList and MeasureFvImage once were implemented in
SecMeasurementTdxLib. The intention of this patch-set is to refactor
SecMeasurementTdxLib to be an instance of TpmMeasurementLib. So these
2 functions (MeasureHobList/MeasureFvImage) are moved to
PeilessStartupLib. This is because:
1. RTMR based trusted boot is implemented in Config-B (See below link)
2. PeilessStartupLib is designed for PEI-less boot and it is the right
place to do the measurement for Hoblist and Config-FV.
Config-B: https://edk2.groups.io/g/devel/message/76367
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
SecTpmMeasurementLitTdx is an instance of TpmMeasurementLib. It is
designed to used in a Td guest. This lib measures and logs data, and
extendx the measurement result into a specific RTMR.
SecTpmMeasurementLibTdx is a refactored lib of
OvmfPkg/Library/SecMeasurementLibTdx and it just copies
GetMappedRtmrIndex/TdxMeasureAndLogData from that lib. At the end of
this patch-set SecMeasurementLibTdx will be deleted.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The generated Makefile was missing a dependency. This resulted in a
build-time race condition if the recursive make is multi-threaded and
shares job control.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Since Cloud Hypervisor doesn't emulate an A20 gate register on I/O port
0x92, it's better to avoid accessing it when the platform is identified
as Cloud Hypervisor.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Since Cloud Hypervisor doesn't support the fw_cfg mechanism, it's more
appropriate to rely on QemuFwCfgLibNull implementation of QemuFwCfgLib
since it provides a null implementation that will not issue any PIO
accesses to ports 0x510 and 0x511.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
There are few places in the codebase assuming QemuFwCfg will be present
and supported, which can cause some issues when trying to rely on the
QemuFwCfgLibNull implementation of QemuFwCfgLib.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
The FW_BASE_ADDRESS value provided by OvmfPkgDefines.fdf.inc is
incorrect for the CloudHv target. We know the generated firmware
contains a PVH ELF header, meaning it will be loaded according to the
address provided through this header. And since we know this address
isn't going to change as it's part of CloudHvElfHeader.fdf.inc, we can
hardcode it through a new include file CloudHvDefines.fdf.inc, which
replaces the generic one OvmfPkgDefines.fdf.inc.
With this change, we prevent the firmware from accessing MMIO addresses
from the address range 0xffc00000-0xffffffff since we know the firmware
hasn't been loaded on this address range.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
microvm places the 64bit mmio space at the end of the physical address
space. So mPhysMemAddressWidth must be correct, otherwise the pci host
bridge setup throws an error because it thinks the 64bit mmio window is
not addressable.
On microvm we can simply use standard cpuid to figure the address width
because the host-phys-bits option (-cpu ${name},host-phys-bits=on) is
forced to be enabled. Side note: For 'pc' and 'q35' this is not the
case for backward compatibility reasons.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
microvm doesn't support pflash and loads the firmware via -bios,
so we can't use the separate CODE and VARS files. Remove them.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
In current TDVF implementation all unaccepted memory passed in Hoblist
are tagged as EFI_RESOURCE_MEMORY_UNACCEPTED. They're all accepted before
they can be accessed. After accepting memory region, the Hob ResourceType
is unchanged (still be EFI_RESOURCE_MEMORY_UNACCEPTED).
TDVF Config-B skip PEI phase and it tries to find a memory region which
is the largest one below 4GB. Then this memory region will be used as the
firmware hoblist.
So we should walk thru the input hoblist and search for the memory region
with the type of EFI_RESOURCE_MEMORY_UNACCEPTED.
Because EFI_RESOURCE_MEMORY_UNACCEPTED has not been officially in PI spec.
So it cannot be defined in MdePkg/Include/Pi/PiHob.h. As a temporary
solution it is defined in Hob.c.
There is a patch-set for lazy-accept very soon. In that patch-set
EFI_RESOURCE_MEMORY_UNACCEPTED will be defined in MdeModulePkg.
Config-B: https://edk2.groups.io/g/devel/message/76367
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled. This check
was not part of the original SEV-ES support and was added in
a91b700e38. Removing the check makes this code consistent with the
Linux kernel
Fixes: a91b700e38 ("Ovmf/ResetVector: Simplify and consolidate the SEV features checks")
Signed-off-by: Peter Gonda <pgonda@google.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
kvm FSB clock is 1GHz, not 100 MHz. Timings are off by factor 10.
Fix all affected build configurations. Not changed: Microvm and
Cloudhw (they have already have the correct value), and Xen (has
no fixed frequency, the PCD is configured at runtime by platform
initialization code).
Fixes: c37cbc030d ("OvmfPkg: Switch timer in build time for OvmfPkg")
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In TDX, Application Processor busy-loops on Mailbox for OS to issue
MpProtectedModeWakeupCommandWakeup command to UEFI. As the AP acking to
it, it clears the command member according to ACPI spec 6.4, 5.2.12.19
Multiprocessor Wakeup Structure: "The application processor need clear the
command to Noop(0) as the acknowledgement that the command is received."
However, AsmRelocateApMailBoxLoop wrongly clears WakeupVector. Correctly
clear command instead of WakeupVector.
Without this patch, TD guest kernel fails to boot APs.
Fixes: fae5c1464d ("OvmfPkg: Add TdxDxe driver")
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
The BaseMemEncryptSevLib functionality was updated to rely on the use of
the OVMF/SEV workarea to check for SEV guests. However, this area is only
updated when running the X64 OVMF build, not the hybrid Ia32/X64 build.
Base SEV support is allowed under the Ia32/X64 build, but it now fails
to boot as a result of the change.
Update the ResetVector code to check for SEV features when built for
32-bit mode, not just 64-bit mode (requiring updates to both the Ia32
and Ia32X64 fdf files).
Fixes: f1d1c337e7
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479
Adds a new library class VariableFlashInfoLib that abstracts access
to variable flash information. The instance provided first attempts
to retrieve information from the Variable Flash Info HOB. If that
HOB is not present, it falls back to the PCDs defined in
MdeModulePkg.
This fall back behavior provides backward compatibility for platforms
that only provide PCDs but also allows platforms that need to
dynamically provide the information using the Variable Flash Info HOB
to do so at runtime.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479
Adds a new GUID that is used to identify a HOB that passes variable
flash information to UEFI variable drivers in HOB consumption phases
such as DXE, Traditional MM, and Standalone MM.
This information was previously passed directly with PCDs such
as EfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
and gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize.
However, the Standalone MM variable driver instance does not have
direct access to the PCD database. Therefore, this HOB will first
be considered as the source for variable flash information and
if platforms do not produce the HOB, reading the information from
the PCDs directly will be a backup to provide backward
compatibility.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Current code follow some rules to check if the PCI device connected to a
serial port device, but some platform or hardware doesn't follow such rule.
By locating gEfiSerialIoProtocolGuid protocol, we can find the related
device path.
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
A little overdesign about VisitAllPciInstances function, since there are
two call back functions. Simplify the code logic by combining the two call
back functions, and unused parameters.
Change the PROTOCOL_INSTANCE_CALLBACK to SIMPLE_PROTOCOL_INSTANCE_CALLBACK
because the former is also defined in OvmfPkg. Rename it to avoid confusion.
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3488
Current free pool routine from PiSmmCore will inspect memory guard status
for target buffer without considering pool headers. This could lead to
`IsMemoryGuarded` function to return incorrect results.
In that sense, allocating a 0 sized pool could cause an allocated buffer
directly points into a guard page, which is legal. However, trying to
free this pool will cause the routine changed in this commit to read XP
pages, which leads to page fault.
This change will inspect memory guarded with pool headers. This can avoid
errors when a pool content happens to be on a page boundary.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Recommend from Gerd:
(2) Keep the EC config option, but update process_files.pl to
automatically add the PcdEcEnabled config option handling
to the files it generates.
When remove 'no-ec' from openssl configure list, will automatically remove
'OPENSSL_NO_EC', 'OPENSSL_NO_ECDH', 'OPENSSL_NO_ECDSA', 'OPENSSL_NO_TLS1_3',
form header, and add '/ec/.', '/sm2/.' files to INF files.
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Move auto-generated openssl config to openssl/opensslconf_generated,
And openssl/opensslconf.h will contain both edk2 conditional openssl
feature and openssl/opensslconf_generated.
Will make two part more clear.
New conditional feture code in opensslconf.h will look like:
/* Autogenerated conditional openssl feature list starts here */
[.....]
/* Autogenerated conditional openssl feature list ends here */
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3917
When PlatformPkg.dsc has multiple SKU IDs but didn't exist delta PCD,
System will hang on BuildPcdDxeDataBase.
Ideally, if didn't exist delta PCD by different SKU ID,
UpdatePcdDatabase () shouldn't return EFI_NOT_FOUND.
Signed-off-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3913
The original flow of PcRtcInit() is like:
1. Guarantee atomic accesses to the RTC time registers and
read out the value.
2. Program RTC register B. (adopt 12h mode or 24h mode. Current
bios code sets RTC to 24h mode by default).
3. Then function ConvertRtcTimeToEfiTime converts the RTC time
value to their 24h mode by checking the hour format bit
(1:24h mode,0:12h mode).
And here lies the problem: Step3 will fail to adjust the value
if Step2 already sets RTC to 24h mode. The hour value in 12h mode
will not be converted to its 24h mode.
The solution is to program RTC register B a little later when all
the original RTC registers' value is retrieved, adjusted
and validated.
ConvertRtcTimeToEfiTime is modified to be more robust.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhuoran Chao <zhuoran.chao@intel.com>
REF? https://bugzilla.tianocore.org/show_bug.cgi?id=3912
UefiCpuPkg define a new Protocol with the new services
SmmWaitForAllProcessor(), which can be used by SMI handler
to optionally wait for other APs to complete SMM rendezvous in
relaxed AP mode.
VariableSmm and VariableStandaloneMM driver in MdeModulePkg need
to use this services but MdeModulePkg can't depend on UefiCpuPkg.
Thus, the solution is moving SmmCpuRendezvouslib.h from UefiCpuPkg
to MdePkg and creating SmmCpuRendezvousLib NullLib version
implementation in MdePkg as dependency for the pkg that can't
depend on UefiCpuPkg.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and
UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build
failure, add CpuLib dependency to all modules that depend on UefiCpuLib.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and
UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build
failure, add CpuLib dependency to all modules that depend on UefiCpuLib.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and
UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build
failure, add CpuLib dependency to all modules that depend on UefiCpuLib.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
The FMMT python tool is used for firmware files operation, which has
the Fv/FFs-based 'View'&'Add'&'Delete'&'Replace' operation function:
1.Parse a FD(Firmware Device) / FV(Firmware Volume) / FFS(Firmware Files)
2.Add a new FFS into a FV file (both included in a FD file or not)
3.Replace an FFS in a FV file with a new FFS file
4.Delete an FFS in a FV file (both included in a FD file or not)
5.Extract the FFS from a FV file (both included in a FD file or not)
This version of FMMT Python tool does not support PEIM rebase feature,
this feature will be added in future update.
Currently the FMMT C tool is saved in edk2-staging repo, but its
quality and coding style can't meet the Edk2 quality, which is hard to
maintain (Hard/Duplicate Code; Regression bugs; Restrict usage).
The new Python version keeps same functions with origin C version. It
has higher quality and better coding style, and it is much easier to
extend new functions and to maintain.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1847
RFC Link: https://edk2.groups.io/g/devel/message/82877
Staging Link: https://github.com/tianocore/edk2-staging/tree/PyFMMT
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
With GNU Make 4.2.1, ifeq ($(EDK2_DSC),"") doesn't catch the case where
EDK2_DSC isn't defined. So, switch to using ifndef.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The debugger in Arm Development Studio 2021.2 doesn't work with
"ec = debugger.getExecutionContext(0)" because it's subsequently unable
to access memory. Fix it by switching to
"ec = debugger.getCurrentExecutionContext()".
The documentation for waitForStop() says:
"It is not needed after a call to stop() because stop() is blocking."
So, remove the call to waitForStop.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
An error message in Scripts/Ds5/edk2_debugger.py was missing the word
'not'.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
QemuFwCfg is much more powerful than BhyveFwCtl. Sadly, BhyveFwCtl
decided to use the same IO ports as QemuFwCfg. It's not possible to use
both interfaces simultaneously. So, prefer QemuFwCfg over BhyveFwCtl.
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Was dropped by accident.
Fixes: b47575801e ("OvmfPkg: move tcg configuration to dsc and fdf include files")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In the Dynamic-Library-File template, add missing output file
declarations. These files are generated by the template and other rules
explicitly depend on them.
This change resolves missing dependency issues we encountered while
running a recursive make with job control.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Try query native display resolution from the host. When successful,
setup PcdVideoHorizontalResolution and PcdVideoVerticalResolution
accordingly and add the video mode to the GOP mode list if needed.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add new function to initialize the GOP, move over setup code. Handle
initialization first, specifically before calling GopQueryMode(), so
GopQueryMode is never called before GopInitialize() did complete.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Call GopQueryMode() in GopSetMode(), use the ModeInfo returned when
setting the mode. This is needed to properly handle modes which are
not on the static mGopResolutions list.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Extend VirtioGpuSendCommand() to support commands which return data,
rename the function to VirtioGpuSendCommandWithReply() to indicate that.
Add a new VirtioGpuSendCommand() function which is just a thin wrapper
around VirtioGpuSendCommandWithReply() so existing code continues to
work without changes.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
ConSplitterDxe will pick the highest available resolution then,
thereby making better use of the available display space.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
ConSplitterDxe will pick the highest available resolution then,
thereby making better use of the available display space.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add modes for a few common display resolutions higher than 800x600,
specifically 1024x768, 1280x800 and 1920x1080, so ConSplitterDxe has
more options available.
The mode list is not use as-is, InitializeGraphicsConsoleTextMode() will
check the list and filter out any modes which don't fit to the screen,
so this will also work fine for small displays.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3828
This is a bugfix of
bf9230a9f3.
1.In the current code, gPlatformFinalPcd will save all PCDs used at
whole compile process, which wastes runtime memory and is unnecessary.
This patch makes gPlatformFinalPcd save only the PCDes which are
assigned in the DSC file, and the PCD that has not been assigned will
use the default value in DEC.
2.During the compilation process, gPlatformFinalPcd may be lost, and
the current code cannot selectively assign PCD in DSC by specifying ARCH.
This patch moves gPlatformFinalPcd into datapipe and modifies the
assignment logicto fix this.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: yi1 li <yi1.li@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3904
TdxDxe driver is introduced for Intel TDX feature. Unfortunately, this
driver also breaks boot process in SEV-ES guest. The root cause is in
the PciLib which is imported by TdxDxe driver.
In a SEV-ES guest the AmdSevDxe driver performs a
MemEncryptSevClearMmioPageEncMask() call against the
PcdPciExpressBaseAddress range to mark it shared/unencrypted. However,
the TdxDxe driver is loaded before the AmdSevDxe driver, and the PciLib
in TdxDxe is DxePciLibI440FxQ35 which will access the
PcdPciExpressBaseAddress range. Since the range has not been marked
shared/unencrypted, the #VC handler terminates the guest for trying to
do MMIO to an encrypted region.
Adjusting the load sequence of TdxDxe and AmdSevDxe can fix the issue.
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
SEV-Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
TDX-Tested-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902
Bad IO performance in SEC phase is observed after TDX features was
introduced. (after commit b6b2de8848 - "MdePkg: Support mmio for
Tdx guest in BaseIoLibIntrinsic").
This is because IsTdxGuest() will be called in each MMIO operation.
It is trying to cache the result of the probe in the efi data segment.
However, that doesn't work in SEC, because the data segment is read only
(so the write seems to succeed but a read will always return the
original value), leading to us calling TdIsEnabled() check for every
mmio we do, which is causing the slowdown because it's very expensive.
This patch is to call CcProbe instead of TdIsEnabled in IsTdxGuest.
Null instance of CcProbe always returns CCGuestTypeNonEncrypted. Its
OvmfPkg version returns the guest type in Ovmf work area.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
1.Added EFIAPI to FspNotifyPhasePeimEntryPoint, SwapStack and
PEI_CORE_ENTRY.
2.Treat both MAX_ADDRESS and MAX_UINT32 as invalid address for
FSP global data in FspApiCallingCheck().
3.Changed AsmReadEsp to AsmReadStackPointer.
4.Changed the type of the return value of AsmReadStackPointer
from UINT32 to UINTN.
5.Changed the type of TemporaryMemoryBase, PermenentMemoryBase
and BootLoaderStack from UINT32 to UINTN.
6.Some type casting to pointers are UINT32. Changed them to
UINTN to accommodate both IA32 and X64.
7.Corrected some typos.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Signed-off-by: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Synced the basetools patch from edk2 repo to
edk2-basetools repo. Update the basetools pip module version
to the latest.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
openssl 3.0 wants at least 512 bytes, otherwise it throws an error:
error:0280007E:Diffie-Hellman routines::modulus too small
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
strcpy() returns a pointer to the destination string, AsciiStrCpyS()
does not. So a simple #define does not work. Create a function
instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add dummy MODULESDIR #define
Will be needed by openssl 3.0.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add define for UINT_MAX.
Will be needed by openssl 3.0.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add #define for INT_MIN.
Will be needed by openssl 3.0.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add #define for strstr().
Will be needed by openssl 3.0.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add fcntl.h header file.
Will be needed by openssl 3.0.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
The payload entry module should support to build as IA32 image
beside X64 image so that it could work with 32bit bootloaders.
This patch adds a option build parameter for arch selection.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Don't assume a 64bit register always holds an address greater than 4GB.
Check the value in the register and decide which Aperature it should be
assigned to.
Fixes assertion
"ASSERT [PciHostBridgeDxe] Bridge->MemAbove4G.Base >= 0x0000000100000000ULL".
Tested with coreboot as bootloader on platforms that have PCI resource
above 4GiB and on platforms that don't have resource above 4GiB.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Guo Dong <guo.dong@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3500
Use efi_debugging.py Python Classes to implement EFI gdb commands:
(gdb) help efi
Commands for debugging EFI. efi <cmd>
List of efi subcommands:
efi devicepath -- Display an EFI device path.
efi guid -- Display info about EFI GUID's.
efi hob -- Dump EFI HOBs. Type 'hob -h' for more info.
efi symbols -- Load Symbols for EFI. Type 'efi_symbols -h' for more info.
efi table -- Dump EFI System Tables. Type 'table -h' for more info.
This module is coded against a generic gdb remote serial stub. It should
work with QEMU, JTAG debugger, or a generic EFI gdb remote serial stub.
No modifications of EFI is required to load symbols.
Example usage:
OvmfPkg/build.sh qemu -gdb tcp::9000
gdb -ex "target remote localhost:9000" -ex "source efi_gdb.py"
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
When default/manufacturing flag get removed from numeric varid, it can't
get default value from StructurePcd in 'UpdateDefaultSettingInFormPackage'
function since there is no EFI_IFR_DEFAULT_OP opcode in IFR file. Add a
chance to get numeric default value from StructurePcd in the case that
numeric minimum value will be used as default value.
Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Makes the following changes to enforce stricter types:
1. PrmPkg/PrmConfigDxe
The function PrmConfigEndOfDxeNotification () is used as a notify
function (of type EFI_EVENT_NOTIFY), however it has a return type
of EFI_STATUS whereas the return type should actually be VOID.
2. PrmPkg/PrmLoaderDxe
Updates the following types to be more accurate than were allowed
in the VS compiler:
* 3rd actual argument given to GetModuleContextBuffers () is
explicitly marked as CONST PRM_MODULE_CONTEXT_BUFFERS **
* 3rd actual argument given to GetContextBuffer () is
explicitly marked as CONST PRM_CONTEXT_BUFFER **
* PrmLoaderEndOfDxeNotification () return type is changed to VOID
to align with the EFI_EVENT_NOTIFY type
3. PrmPkg/Application/PrmInfo
Updates the following types to be more accurate than were allowed
in the VS compiler:
* SHELL_STATUS in ParseParameterList () is now EFI_STATUS
* 3rd actual argument given to GetModuleContextBuffers () is
explicitly marked as CONST PRM_MODULE_CONTEXT_BUFFERS **
* 3rd actual argument given to GetContextBuffer () is
explicitly marked as CONST PRM_CONTEXT_BUFFER **
Cc: Andrew Fish <afish@apple.com>
Cc: Kang Gao <kang.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Ankit Sinha <ankit.sinha@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ankit Sinha <ankit.sinha@intel.com>
Adds a new UEFI application called "PrmInfo" that allows a user
to display and test Platform Runtime Mechanism (PRM) modules.
Execute the application help command for detailed usage
instructions and examples of how to use the application:
"PrmInfo -?"
This application is intended to be helpful during PRM enabling
by allowing the user to:
1. Confirm that their firmware port of the PRM infrastructure
implemented in this package is functioning correctly.
2. Quickly get information about what PRM modules and handlers
are present on a given system.
3. Quickly test PRM handlers without booting to a fully featured
operating system.
4. Develop and exercise PRM handlers prior to the availability of
an operating system that is PRM aware.
Adds a brief section to Readme.md about the PrmInfo UEFI application
with a link to allow the reader to find more information about the
application if interested.
Cc: Andrew Fish <afish@apple.com>
Cc: Kang Gao <kang.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Ankit Sinha <ankit.sinha@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ankit Sinha <ankit.sinha@intel.com>
The PRM_MODULE_EXPORT parameterized macro allows a caller to produce
a static PRM module export descriptor structure in the binary by
simply passing PRM_HANDLER_EXPORT_ENTRY arguments with each argument
representing a PRM handler to be exported by the module.
Previously, the PRM_MODULE_EXPORT_DESCRIPTOR_STRUCT used in the
PRM_MODULE_EXPORT macro was fixed to a maximum of three handlers.
This change removes that restriction and allows the structure to
grow based on the number of PRM handlers given to the macro. This
means a local type will be customized per PRM module. The reference
type PRM_MODULE_EXPORT_DESCRIPTOR_STRUCT keeps a field at the end
that allows array access to PRM_HANDLER_EXPORT_DESCRIPTOR_STRUCT
members.
Cc: Andrew Fish <afish@apple.com>
Cc: Kang Gao <kang.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Ankit Sinha <ankit.sinha@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ankit Sinha <ankit.sinha@intel.com>
There's currently two approaches being considered for how to allocate the
context buffer passed to PRM handlers:
1. The context buffer is allocated and populated in firmware. As such, the
FW converts all pointers internal to the buffer to virtual memory
addresses at the virtual address change event. A single context buffer
pointer is given to the OS via the PRM ACPI table and the OS converts
this single physical address to a virtual address when it passes the
context buffer as a pointer to PRM handlers.
2. The context buffer is allocated and populated in the OS. The OS gets
all the information needed to populate the context buffer from other
pre-existing resources (mainly physical addresses in the PRM ACPI
table). The OS converts all the physical addresses to virtual addresses,
allocates the context buffer instances, and fills in the information.
The OS passes the context buffer virtual address to PRM handlers.
The prior behavior was (1). The current POR behavior has moved to (2).
Until (2) is used more widely, it can be kept around with fairly minimal
overhead via a build flag in a few places.
So the default behavior is now (2) (the expected permanent behavior) with
(1) easily enabled by defining "ALLOCATE_CONTEXT_BUFFER_IN_FW" in the
compiler defined macros. A DSC define was added in PrmPkg.dsc to set this
compiler macro in the package build.
At some point in the future, all code (and some peripheral code)
surrounded with this build flag can be removed if (2) is fully
decided upon.
Cc: Andrew Fish <afish@apple.com>
Cc: Kang Gao <kang.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Ankit Sinha <ankit.sinha@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ankit Sinha <ankit.sinha@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3812
Adds a new package to maintain Platform Runtime Mechanism (PRM)
support.
This package is intended to include generic code that provides a
common infrastructure to support PRM in firmware and a collection
of sample PRM modules that demonstrate how to use the interfaces
and other package resources to author a PRM module.
The following initial headers are included in this commit:
* Prm.h - Includes common content for PRM with no dependencies on
other PRM header files.
* PrmContextBuffer.h - Includes definitions for PRM context buffers.
Context buffers are standardized structures that point to various
resources available to a PRM handler during its execution.
* PrmDataBuffer.h - Includes definitions for PRM data buffers.
Within the context of PRM, these data buffers are composed of a
generic header followed by a variable length blob of arbitrary
data.
* PrmExportDescriptor.h - Includes definitions for creating PRM
export descriptors.
A PRM export descriptor is a structure referenced in the export
table of PRM module that contains PRM-specific metadata about the
module.
* PrmMmio.h - Includes definitions for describing MMIO ranges uses
by PRM modules.
* PrmModule.h - Includes definitions commonly used by PRM module
authors.
This file is provided to serve as a convenient include for PRM
module authors.
* PrmOsServices.h - Includes content specific to PRM OS services.
OS Services will not planned to be present in the final version
of PRM. The OS Services have been reduced to a simple debug print
function. So this is currently planned to be a temporary file to
support debugging during PRM development.
Note: Modules built for the UEFI environment can be built by Visual
Studio and non-Visual Studio toolchains. However, PRM modules
are currently only supported on Visual Studio toolchain due to
usage of export tables.
Cc: Andrew Fish <afish@apple.com>
Cc: Kang Gao <kang.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Ankit Sinha <ankit.sinha@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ankit Sinha <ankit.sinha@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3880
Currently UncrustifyCheck.py provides the following exclusion
options:
1. Override the type of files UncrustifyCheck operates against by
default (.c and .h files). Using the "IgnoreStandardPaths"
configuration option.
2. By default, UncrustifyCheck skips files in git submodules and
ignored by git (the "SkipGitExclusions" configuration option can
override this behavior).
The goal of UncrustifyCheck is to provide consistent formatting
across the codebase. In some rare circumstances, maintainers might
need to exclude a specific file (or file pattern) within their
package. For example, a small set of auto-generated files from
another repository.
This change adds a new configuration option that can be specified
in a package CI YAML file to describe a list of files within the
package that should be ignored by UncrustifyCheck.
The configuration option is called "IgnoreFiles" and it uses similar
syntax to git ignore to ignore a list of files.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
1. Use PeiDxeDebugLibReportStatusCode library for DebugLib, and add
ReportStatusCodeLib.
2. Remove gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize
overrided in UefiPayloadPkg.dsc.
3. Change PcdHardwareErrorRecordLevel to 1
Cc: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Intel's Trust Domain Extensions (Intel TDX) refers to an Intel technology
that extends Virtual Machines Extensions (VMX) and Multi-Key Total Memory
Encryption (MKTME) with a new kind of virutal machines guest called a
Trust Domain (TD). A TD is desinged to run in a CPU mode that protects the
confidentiality of TD memory contents and the TD's CPU state from other
software, including the hosting Virtual-Machine Monitor (VMM), unless
explicitly shared by the TD itself.
There are 2 configurations for TDVF to upstream. See below link for
the definitions of the 2 configurations.
https://edk2.groups.io/g/devel/message/76367
This patch-set is to enable the basic feature of Config-B in OvmfPkg.
- Add a standalone IntelTdxX64.dsc to a TDX specific directory for a
*full* feature TDVF. (Align with existing SEV)
- IntelTdx.dsc includes Tdx/Legacy OVMF basic boot capability. The
final binary can run on Tdx/Legacy OVMF.
- PEI phase is skipped.
By design in Config-B there should be more advanced features, such as:
- RTMR based measurement and measure boot.
- Remove unnecessary drivers to reduce attack surface, such as
network stack.
To make the code review more efficiency, Config-B is split into 2 waves:
- Basic feature of Config-B
- Advanced feature of Config-B
This patch contains 2 files (IntelTdxX64.dsc/IntelTdxX64.fdf) which
enable the basic feature of Config-B. In the waves of Advanced feature
of Config-B, we will re-visit these 2 files.
TDX_PEI_LESS_BOOT is defined in IntelTdxX64.dsc to indicate it boots up
without PEI phase.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
PeilessStarupLib provides a function (PeilessStartup) which brings
up both Legacy and Tdx guest from SEC phase to DXE phase. PEI phase
is skipped so that the attack surfaces are reduced as much as possible.
PeilessStartup() does below tasks:
1. Contruct the FW hoblist.
Since PEI is skipped, we must find a memory region which is the
largest one below 4GB. Then this memory region will be used as the
firmware hoblist.
2. Initialize the platform.
3. Build various Hobs, such as SecFv Hob, DxeFv Hob, Stack Hob, etc.
4. At last DXE Core is located / loaded and transfer control to it.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711
Discussion in https://bugzilla.tianocore.org/show_bug.cgi?id=1496 shows
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.
CSM support was moved in 2019 too. (CSM support depends on 8254/8259
drivers). So 8254TimerDxe will be used when CSM_ENABLE=TRUE.
There are 4 .dsc which include the 8254Timer.
- OvmfPkg/AmdSev/AmdSevX64.dsc
- OvmfPkg/OvmfPkgIa32.dsc
- OvmfPkg/OvmfPkgIa32X64.dsc
- OvmfPkg/OvmfPkgX64.dsc
For the three OvmfPkg* configs using 8254TimerDxe with CSM_ENABLE=TRUE
and LapicTimerDxe otherwise.
For the AmdSev config it doesn't make sense to support a CSM. So use
the lapic timer unconditionally.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
The IOMMU protocol driver provides capabilities to set a DMA access
attribute and methods to allocate, free, map and unmap the DMA memory
for the PCI Bus devices.
The current IoMmuDxe driver supports DMA operations inside SEV guest.
To support DMA operation in TDX guest,
CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr) is used to determine
if it is SEV guest or TDX guest.
Due to security reasons all DMA operations inside the SEV/TDX guest must
be performed on shared pages. The IOMMU protocol driver for the SEV/TDX
guest uses a bounce buffer to map guest DMA buffer to shared pages in
order to provide the support for DMA operations inside SEV/TDX guest.
The call of SEV or TDX specific function to set/clear EncMask/SharedBit
is determined by CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr).
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
TdxDxe driver is dispatched early in DXE, due to being list in APRIORI.
This module is responsible for below features:
- Sets max logical cpus based on TDINFO
- Sets PCI PCDs based on resource hobs
- Set shared bit in MMIO region
- Relocate Td mailbox and set its address in MADT table.
1. Set shared bit in MMIO region
Qemu allows a ROM device to set to ROMD mode (default) or MMIO mode.
When it is in ROMD mode, the device is mapped to guest memory and
satisfies read access directly.
In EDK2 Option ROM is treated as MMIO region. So Tdx guest access
Option ROM via TDVMCALL(MMIO). But as explained above, since Qemu set
the Option ROM to ROMD mode, the call of TDVMCALL(MMIO) always return
INVALID_OPERAND. Tdvf then falls back to direct access. This requires
to set the shared bit to corresponding PageTable entry. Otherwise it
triggers GP fault.
TdxDxe's entry point is the right place to set the shared bit in MMIO
region because Option ROM has not been discoverd yet.
2. Relocate Td mailbox and set the new address in MADT Mutiprocessor
Wakeup Table.
In TDX the guest firmware is designed to publish a multiprocessor-wakeup
structure to let the guest-bootstrap processor wake up guest-application
processors with a mailbox. The mailbox is memory that the guest firmware
can reserve so each guest virtual processor can have the guest OS send
a message to them. The address of the mailbox is recorded in the MADT
table. See [ACPI].
TdxDxe registers for protocol notification
(gQemuAcpiTableNotifyProtocolGuid) to call the AlterAcpiTable(), in
which MADT table is altered by the above Mailbox address. The protocol
will be installed in AcpiPlatformDxe when the MADT table provided by
Qemu is ready. This is to maintain the simplicity of the AcpiPlatformDxe.
AlterAcpiTable is the registered function which traverses the ACPI
table list to find the original MADT from Qemu. After the new MADT is
configured and installed, the original one will be uninstalled.
[ACPI] https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model
/ACPI_Software_Programming_Model.html#multiprocessor-wakeup-structure
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
In TDX the guest firmware is designed to publish a multiprocessor-wakeup
structure to let the guest-bootstrap processor wake up guest-application
processors with a mailbox. The mailbox is memory that the guest firmware
can reserve so each guest virtual processor can have the guest OS send
a message to them. The address of the mailbox is recorded in the MADT
table. See [ACPI].
To maintain the simplicity of the AcpiPlatformDxe, the MADT ACPI table
will be altered in another driver (TdxDxe) by installing a protocol
to notify that the ACPI table provided by Qemu is ready. Then in TdxDxe
a notification functioin will be called to alter the MADT table to recorded
the mailbox address.
The protocol is gQemuAcpiTableNotifyProtocolGuid.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
There are below changes in PlatformInitLib for Tdx guest:
1. Publish ram regions
In Tdx guest, the system memory is passed in TdHob by host VMM. So
the major task of PlatformTdxPublishRamRegions is to walk thru the
TdHob list and transfer the ResourceDescriptorHob and MemoryAllocationHob
to the hobs in DXE phase.
2. Build MemoryAllocationHob for Tdx Mailbox and Ovmf work area.
3. Update of PlatformAddressWidthInitialization. The physical
address width that Tdx guest supports is either 48 or 52.
4. Update of PlatformMemMapInitialization.
0xA0000 - 0xFFFFF is VGA bios region. Platform initialization marks the
region as MMIO region. Dxe code maps MMIO region as IO region.
As TDX guest, MMIO region is maps as shared. However VGA BIOS doesn't need
to be shared. Guest TDX Linux maps VGA BIOS as private and accesses for
BIOS and stuck on repeating EPT violation. VGA BIOS (more generally ROM
region) should be private. Skip marking VGA BIOA region [0xa000, 0xfffff]
as MMIO in HOB.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
There are below major changes in this commit.
1. SecEntry.nasm
In TDX BSP and APs goes to the same entry point in SecEntry.nasm.
BSP initialize the temporary stack and then jumps to SecMain, just as
legacy Ovmf does.
APs spin in a modified mailbox loop using initial mailbox structure.
Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h.
APs wait for command to see if the command is for me. If so execute the
command.
2. Sec/SecMain.c
When host VMM create the Td guest, the system memory informations are
stored in TdHob, which is a memory region described in Tdx metadata.
The system memory region in TdHob should be accepted before it can be
accessed. So the major task of this patch is to process the TdHobList
to accept the memory. After that TDVF follow the standard OVMF flow
and jump to PEI phase.
PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives
no chance for Intel TDX to support 1G page table. To support 1G page
table this PCD is set to TRUE in OvmfPkgX64.dsc.
TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the
Tdx specific code.
TDX only works on X64, so the code is only valid in X64 arch.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
When host VMM create the Td guest, the system memory informations are
stored in TdHob, which is a memory region described in Tdx metadata.
The system memory region in TdHob should be accepted before it can be
accessed. So the newly added function (ProcessTdxHobList) is to process
the TdHobList to accept the memory. Because TdHobList is provided by
host VMM which is not trusted, so its content should be checked before
it is consumed by TDVF.
Because ProcessTdxHobList is to be called in SEC phase, so
PlatformInitLib.inf is updated to support SEC.
Note: In this patch it is BSP which accepts the pages. So there maybe
boot performance issue. There are some mitigations to this issue, such
as lazy accept, 2M accept page size, etc. We will re-visit here in the
future.
EFI_RESOURCE_MEMORY_UNACCEPTED is a new ResourceType in
EFI_HOB_RESOURCE_DESCRIPTOR. It is defined for the unaccepted memory
passed from Host VMM. This is proposed in microsoft/mu_basecore#66
files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9
e4R237 according to UEFI-Code-First. The proposal was approved in 2021
in UEFI Mantis, and will be added to the new PI.next specification.
Per the MdePkg reviewer's comments, before this new ResourceType is
added in the PI spec, it should not be in MdePkg. So it is now
defined as an internal implementation and will be moved to
MdePkg/Include/Pi/PiHob.h after it is added in PI spec.
See https://edk2.groups.io/g/devel/message/87641
PcdTdxAcceptPageSize is added for page accepting. Currently TDX supports
4K and 2M accept page size. The default value is 2M.
Tdx guest is only supported in X64. So for IA32 ProcessTdxHobList
just returns EFI_UNSUPPORTED.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863
The intention of PlatformInitLib is to extract the common function used
in OvmfPkg/PlatformPei. This lib will be used not only in PEI phase but
also in SEC phase. SEC phase cannot use global variables between
different functions. So PlatformInfoHob is created to hold the
informations shared between functions. For example, HostBridgeDevId
corespond to mHostBridgeDevId in PlatformPei.
In this patch we will first move below global variables to
PlatformInfoHob.
- mBootMode
- mS3Supported
- mPhysMemAddressWidth
- mMaxCpuCount
- mHostBridgeDevId
- mQ35SmramAtDefaultSmbase
- mQemuUc32Base
- mS3AcpiReservedMemorySize
- mS3AcpiReservedMemoryBase
PlatformInfoHob also holds other information, for example,
PciIoBase / PciIoSize. This is because in SEC phase, PcdSetxxx
doesn't work. So we will restruct the functions which set PCDs
into two, one for PlatformInfoLib, one for PlatformPei.
So in this patch we first move global variables and PCDs to
PlatformInfoHob. All the changes are in OvmfPkg/PlatformPei.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863
There are 3 variants of PlatformPei in OvmfPkg:
- OvmfPkg/PlatformPei
- OvmfPkg/XenPlatformPei
- OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf
These PlatformPeis can share many common codes, such as
Cmos / Hob / Memory / Platform related functions. This commit
(and its following several patches) are to create a PlatformInitLib
which wraps the common code called in above PlatformPeis.
In this initial version of PlatformInitLib, below Cmos related functions
are introduced:
- PlatformCmosRead8
- PlatformCmosWrite8
- PlatformDebugDumpCmos
They correspond to the functions in OvmfPkg/PlatformPei:
- CmosRead8
- CmosWrite8
- DebugDumpCmos
Considering this PlatformInitLib will be used in SEC phase, global
variables and dynamic PCDs are avoided. We use PlatformInfoHob
to exchange information between functions.
EFI_HOB_PLATFORM_INFO is the data struct which contains the platform
information, such as HostBridgeDevId, BootMode, S3Supported,
SmmSmramRequire, etc.
After PlatformInitLib is created, OvmfPkg/PlatformPei is refactored
with this library.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Intel TDX architecture does not prescribe a specific software convention
to perform I/O from the guest TD. Guest TD providers have many choices to
provide I/O to the guest. The common I/O models are emulated devices,
para-virtualized devices, SRIOV devices and Direct Device assignments.
TDVF chooses para-virtualized I/O (Choice-A) which use the TDG.VP.VMCALL
function to invoke the funtions provided by the host VMM to perform I/O.
Another choice (Choice-B) is the emulation performed by the #VE handler.
There are 2 benefits of para-virtualized I/O:
1. Performance.
VMEXIT/VMENTRY is skipped so that the performance is better than #VE
handler.
2. De-couple with #VE handler.
Choice-B depends on the #VE handler which means I/O is not available
until #VE handler is installed. For example, in PEI phase #VE handler
is installed in CpuMpPei, while communication with Qemu (via I/O port)
happen earlier than it.
IoLibInternalTdx.c provides the helper functions for Tdx guest.
IoLibInternalTdxNull.c provides the null version of the helper functions.
It is included in the Non-X64 IoLib so that the build will not be broken.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
This fixes an issue where the framebuffer provided by coreboot or
slimbootloader will only work on the primary VGA device. If the
framebuffer corresponds to a different device the screen will stay black.
In addition, the code doesn't work for multiple graphic cards, has
reference to non existing functions, and is a duplication of common code.
Call EfiBootManagerConnectVideoController on every display device found,
not only the legacy VGA device. This is the same as OvmfPkg does.
Allows to display output on the framebuffer set up by firmware, which might
not be the VGA device.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
On modern platforms with TBT devices the coreboot resource allocator
opens large PCI bridge MMIO windows above 4GiB to place hotplugable
PCI BARs there as they won't fit below 4GiB. In addition modern
GPGPU devices have very big PCI bars that doesn't fit below 4GiB.
The PciHostBridgeLib made lots of assumptions about the coreboot
resource allocator that were not verified at runtime and are no
longer true.
Remove all of the 'coreboot specific' code and implement the same
logic as OvmfPkg's ScanForRootBridges.
Fixes assertion
"ASSERT [PciHostBridgeDxe] Bridge->Mem.Limit < 0x0000000100000000ULL".
Tested with coreboot as bootloader on platforms that have PCI resources
above 4GiB and on platforms that don't have resources above 4GiB.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
On windows build, need add "-DPLATFORMX64_ENABLE=TRUE" in the build
command line beside -DNETWORK_DRIVER_ENABLE=TRUE in order build
network features. So update DSC to set PLATFORMX64_ENABLE to TRUE
when building network feature.
On Linux build, DSC file should not have PcdAllowHttpConnections
without building network feature, else it would cause build error.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by Sean Rhodes <sean@starlabs.systems>
In function ?SetDevicePathEndNode?,
inlined from ?FileDevicePath? at DevicePathUtilities.c:857:5:
DevicePathUtilities.c:321:3: error: writing 4 bytes into a region of size 1 [-Werror=stringop-overflow=]
321 | memcpy (Node, &mUefiDevicePathLibEndDevicePath, sizeof (mUefiDevicePathLibEndDevicePath));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from UefiDevicePathLib.h:22,
from DevicePathUtilities.c:16:
../Include/Protocol/DevicePath.h: In function ?FileDevicePath?:
../Include/Protocol/DevicePath.h:51:9: note: destination object ?Type? of size 1
51 | UINT8 Type; ///< 0x01 Hardware Device Path.
| ^~~~
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Sdk/C/LzmaEnc.c: In function ?LzmaEnc_CodeOneMemBlock?:
Sdk/C/LzmaEnc.c:2828:19: error: storing the address of local variable ?outStream? in ?*p.rc.outStream? [-Werror=dangling-pointer=]
2828 | p->rc.outStream = &outStream.vt;
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?outStream? declared here
2811 | CLzmaEnc_SeqOutStreamBuf outStream;
| ^~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?pp? declared here
Sdk/C/LzmaEnc.c:2828:19: error: storing the address of local variable ?outStream? in ?*(CLzmaEnc *)pp.rc.outStream? [-Werror=dangling-pointer=]
2828 | p->rc.outStream = &outStream.vt;
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?outStream? declared here
2811 | CLzmaEnc_SeqOutStreamBuf outStream;
| ^~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?pp? declared here
cc1: all warnings being treated as errors
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Pick up bugfixes from latest openssl release. Includes CVE-2022-0778
fix (I don't think edk2 is affected though due to EC being disabled).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
For the multiple SKU case, basetools generates multiple redundant
__FLEXIBLE_SIZE statement that is from the same line in dsc file.
This behavior causes the generated PcdValueInit.c file to have huge size,
and the compilation time is very long.
This patch is going to fix this issue.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3828
FeatureFlagExpression Support in Source section of INF file. The Pcd
value in the expression is from INF or DEC.
When a FeatureFlagExpression is present,if the expression evaluates
to TRUE,then the entry is valid. If the expression evaluates to FALSE,
then the EDK II build tools must ignore the entry.
This patch is going to add this feature.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Heng Luo <heng.luo@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Yi Li <yi1.li@intel.com>
Previous commit fixed that check in DXE, this one now for PEI.
Signed-off-by: Mara Sophie Grosch <littlefox@lf-net.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Fix the check for NVMe command set being supported by the controller.
Was problematic with qemu (6.2.0, Debian 1:6.2+dfsg-3), which sets 0xC1
in that register, making the OVMF think the NVMe controller does not
support NVMe.
Uncovered by commit 9dd14fc91c, which
changed the number of bits included in the Css register from 4 to 8.
Signed-off-by: Mara Sophie Grosch <littlefox@lf-net.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Starting from ACPI Specification Version 5.1 Errata B, the term
'Correctable' is no longer being used as an error severity of the
reported error in Chapter 18 APEI.
This commit will
a) For Acpi40.h & Acpi50.h
Add new macro EFI_ACPI_X_X_ERROR_SEVERITY_RECOVERABLE, since both the
terms 'Correctable' and 'Recoverable' are used to denote the same error
severity.
b) Header files starting from Acpi51.h to Acpi64.h
Add new macro EFI_ACPI_X_X_ERROR_SEVERITY_RECOVERABLE.
Keeps the origin EFI_ACPI_X_X_ERROR_SEVERITY_CORRECTABLE for compatibility
consideration, but add comments to mark it as deprecated and should no
longer be used.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Adds following changes
1) Added support for manufacturing mode in
BIOS Characteristics Extension Byte 2.
2) Added support for slot height in
System Slot Table (type 9).
3) Updated Built-in pointing device interface with
USB, I2C and SPI.
4) Updates Onboard Devices Extended Information with
wireless LAN, bluetooth, WWAN, eMMC, NVMe and UFC.
5) Added new table Firmware Inventory Information (Type 45)
and its corresponding enum values.
6) Added new table String Property Table (Type 46)
and its corresponding enum values.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3802
Since PRM module needs to support export table in PE-COFF, we'll
enhance GenFw tool to support this.
Add one export flag in GenFw tool. If export flag is set:
Step1: Scan ELF symbol table based on PRM module descriptor to get
descriptor offset address;
Step2: Find PRM handlers number and name in COFF file based on the
address from step1;
Step3: Write PRM info such as handler name and export RVA into COFF
export table.
PRM option currently only supports DXE RUNTIME driver and X64 arch.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Lixia Huang <lisa.huang@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
According to the Debug Port Table 2 (DBG2) specification,
February 17, 2021, the NamespaceString is a NULL terminated
ASCII string that consists of a fully qualified reference
to the object that represents the serial port device in the
ACPI namespace.
The DBG2 table generator did not populate the full device
path for the serial port device, and this results in a FWTS
test failure.
Therefore, populate the full namespace device path for the
serial port in DBG2 table.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Jagadeesh Ujja <Jagadeesh.Ujja@arm.com>
Tested-by: Sunny Wang <sunny.wang@arm.com>
When build option ABOVE_4G_MEMORY is set to true, nothing will change
and EDKII will use all available memory.
Setting it to false will create memory type information HOB in
payload entry, so that EDKII will reserve enough memory below 4G
for EDKII modules. This option is useful for bootloaders that are not
fully 64-bit aware such as Qubes R4.0.4 bootloader, Zorin and Proxmox.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification, which requires
less emulation from the VMM.
The fdf include file CloudHvElfHeader.fdf.inc has been generated from
the following commands:
$ gcc -D PVH64 -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 4194304 OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
CloudHv doesn't need any VARS store, and it doesn't need the CODE
section to be generated separately either. The only thing needed is to
generate a firmware binary that can be used by Cloud Hypervisor.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Updating the fdf include file based on the run of the ELF header
generator. The diff from this patch is the result of:
$ gcc -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 2097152 OvmfPkg/XenElfHeader.fdf.inc
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Instead of having the PVH ELF header part of the fdf file directly, we
move it to a dedicated include file. This is the first step in
automating the generation of the header.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Adding some flexibility to the program through optional parameters and
global define, so that other targets can use the generator.
* A global define is added so that we can choose at build time if we
want to use 32-bit or 64-bit base structures.
* A first optional parameter is added so the user can provide the
expected blob size of the generated binary.
* A second optional parameter is added so the user can specify an output
file to which the generated output will be printed.
The default behavior isn't modified.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
No need to check the interface protocol then conditionally setting,
just set it to BOOT_PROTOCOL and check for error.
This is what Linux does for HID devices as some don't follow the USB spec.
One example is the Aspeed BMC HID keyboard device, which adds a massive
boot delay without this patch as it doesn't respond to
'GetProtocolRequest'.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3818
It will have some potential issue when memory larger than 2G because
the high memory address will be fill with 0xFFFFFFFF when do the
operation of INTN + INT64 but it is 32 bit normal data in fact.
Should use same data type INT64 + INT64.
V3:
1. Use INT64 as input parameter because all date type is 64 bit
V2:
1. Force the data type to UINTN to avoid high dword be filled with
0xFFFFFFFF
2. Keep INTN because the offset may postive or negative.
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Guomin Jiang <guomin.jiang@intel.com>
Move the logic that stores starting PCI attributes and sets the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute to
DriverBindingStart() before the memory that backs the
DMA engine is allocated.
This ensures that the DMA-backing memory is not forcibly allocated
below 4G in system address map. Otherwise the allocation fails on
platforms that do not have any memory below the 4G mark and the drive
initialisation fails.
Leave the PCI device enabling attribute logic in NvmeControllerInit()
to ensure that the device is re-enabled on reset in case it was
disabled via PCI attributes.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Tomas Pilar <quic_tpilar@quicinc.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
The SNP patch series updated the OvmfPkgX64 build but forgot the AmdSev
variant, resulting in a broken OvmfSevMetadata table.
Fixes: cca9cd3dd6 ("OvmfPkg: reserve CPUID page")
Fixes: 707c71a01b ("OvmfPkg: reserve SNP secrets page")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Use the correct PCD type for PcdPlatformBootTimeOut so it gets wired up
to the Timeout EFI variable automatically, which is how the boot manager
stores the timeout preference.
Note that this changes the default to 5 seconds, which appears to be
common across platforms.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Alex reports that the cache invalidation performed by
ArmVirtMemoryInitPeiLib takes a non-negligible amount of time at boot.
This cache invalidation used to be necessary to avoid inconsistencies
between the CPU's cached and uncached views of the permanent PEI memory
region, given that the PEI phase is where the MMU gets enabled.
The only allocations done from permanent PEI memory with the MMU off are
pages used for page tables, and since commit 748fea6279
("ArmPkg/ArmMmuLib AARCH64: invalidate page tables before populating
them"), each of those is invalidated in the caches explicitly, for
reasons described in the patch's commit log. All other allocations done
in PEI are either from temporary PEI memory, which includes the stack,
or from permanent PEI memory but after the MMU has been enabled.
This means that the cache invalidation in ArmVirtMemoryInitPeiLib is no
longer necessary, and can simply be dropped.
Reported-by: Alexander Graf <graf@amazon.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-02-25 15:57:11 +00:00
856 changed files with 61590 additions and 10824 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
