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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3835
The commit ade62c18f4 caused a boot failure
when OVMF is build with SECURE_BOOT/SMM enabled.
This happen because the above commit extended the BaseMemEncryptSevLib.inf
to include VmgExitLib. The FvbServicesSmm uses the functions provided
by the MemEncryptSevLib to clear the memory encryption mask from the
page table. It created a dependency, as shown below
OvmfPkg/FvbServicesSmm.inf
---> MemEncryptSevLib class
---> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance
---> VmgExitLib
---> "OvmfPkg/VmgExitLib" instance
---> LocalApicLib class
---> UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf instance
---> TimerLib class
---> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance
---> PciLib class
---> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance
The LocalApicLib provides a constructor, execution of the constructor
causes an exception. The SEV-ES and SEV-SNP do not support the SMM, so
skip including the VmgExitLib chain. Use the module override to use the
VmgExitLibNull to avoid the inclusion of unneeded LocalApicLib dependency
chain in FvbServicesSmm. We ran similar issue for AmdSevDxe driver,
see commit 19914edc5a
After the patch, the dependency look like this:
OvmfPkg/FvbServicesSmm.inf
---> MemEncryptSevLib class
---> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance
---> VmgExitLib
---> "UefiCpuPkg/Library/VmgExitLibNull" instance
Fixes: ade62c18f4
Reported-by: Aaron Young <aaron.young@oracle.com>
Cc: Dann Frazier <dann.frazier@canonical.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
XCODE5 reported the following warning:
OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1895:12: note:
uninitialized use occurs here
Compacted
^^^^^^^^^
Initialize the 'Compacted' variable to fix the warning.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Building with the CLANG35 and CLANG38 toolset fails because of variables
which are set but not otherwise used in the RELEASE build.
GCC added -Wno-unused-but-set-variable back in 2016, and later added
-Wno-unused-const-variable. Add those to CLANG35_WARNING_OVERRIDES and
CLANG38_WARNING_OVERRIDES.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
When setting mVirtualMap to NULL also set mVirtualMapMaxIndex to 0.
Without that RuntimeDriverConvertPointer() will go search the ZeroPage
for EFI_MEMORY_DESCRIPTOR entries.
In case mVirtualMapMaxIndex happens to be small small enough that'll go
unnoticed, the search will not find anything and EFI_NOT_FOUND will be
returned.
In case mVirtualMapMaxIndex is big enough the search will reach the end
of the ZeroPage and trigger a page fault.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Fix a Edk2Logger.warn() message format to match the arguments.
We ran into this after a failure in PcdValueInit. The failure was
masked by a new exception, "TypeError: not all arguments converted
during string formatting".
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3770 (https://bugzilla.tianocore.org/show_bug.cgi?id=3770)
The PPTT parser in AcpiView incorrectly dereferences a pointer to
FlagName when trying to log an error with the PPTT cache flags, which
can lead to random crashes and other errors.
Also fix some spacing in the error message to ensure the message is
printed cleanly.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3811
Remove ASSERT() statements that are triggered if a platform provides
an override of PCI ROM attached to a PCI Controller. The PCI Platform
Protocol allows the platform to provide a PCI ROM image for a PCI
Controller. This works for PCI Controllers that do not have an attached
PCI ROM, but the platform is not allowed to replace the PCI ROM for a
PCI Controller that has its own PCI ROM. Removing these ASSERT()
statements enables this additional use case.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
In AmlCodeGenReturn, the cast to AML_NODE_HEADER* in the call to
AmlSetFixedArgument is redundant because ReturnNode is already a
AML_NODE_HEADER* .
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
We never run any code at EL0, and so it would seem that any access
permissions set for EL0 (via the AP[1] attribute in the page tables) are
irrelevant. We currently set EL0 and EL1 permissions to the same value
arbitrarily.
However, this causes problems on hardware like the Apple M1 running the
MacOS hypervisor framework, which enters EL1 with SCTLR_EL1.SPAN
enabled, causing the Privileged Access Never (PAN) feature to be enabled
on any exception taken to EL1, including the IRQ exceptions that handle
our timer interrupt. When PAN is enabled, EL1 has no access to any
mappings that are also accessible to EL0, causing the firmware to crash
if it attempts to access such a mapping.
Even though it is debatable whether or not SCTLR_EL1.SPAN should be
disabled at entry or whether the firmware should put all UNKNOWN bits in
all system registers in a consistent state (which it should), using EL0
permissions serves no purpose whatsoever so let's fix that regardless.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexander Graf <agraf@csgraf.de>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Acpiview is a command line tool allowing to display, dump, or check
installed ACPI tables. Add a 'ACPIVIEW_ENABLE' switch to enable it
on an ArmVirt platform.
The switch is set for the ArmVirtKvmTool platform.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
A Configuration Manager that uses the Dynamic Tables framework
to generate ACPI tables for Kvmtool Guests has been provided.
This Configuration Manager uses the FdtHwInfoParser module to
parse the Kvmtool Device Tree and generate the required
Configuration Manager objects for generating the ACPI tables.
Therefore, enable ACPI table generation for Kvmtool.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3742
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add Configuration Manager to enable ACPI tables for Kvmtool
firmware. The Configuration Manager for Kvmtool uses the DT
Hardware Information Parser module (FdtHwInfoParser) to parse
the DT provided by Kvmtool. The FdtHwInfoParser parses the DT
and invokes the callback function HW_INFO_ADD_OBJECT to add
the Configuration Manager objects to the Platform Information
repository.
The information for some Configuration Manager objects may not
be available in the DT. Such objects are initialised locally
by the Configuration Manager.
Support for the following ACPI tables is provided:
- DBG2
- DSDT (Empty stub)
- FADT
- GTDT
- MADT
- SPCR
- SSDT (Cpu Hierarchy)
- SSDT (Pcie bus)
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Most ACPI tables for Kvmtool firmware are dynamically
generated. The AML code is also generated at runtime
for most components in appropriate SSDTs.
Although there may not be much to describe in the DSDT,
the DSDT table is mandatory.
Therefore, add an empty stub for DSDT.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The cpsell tool checks for unknown words in the upstream CI.
Add some new words to the list of exceptions.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In ACPI 6.4, s6.2.13, _PRT objects describing PCI legacy interrupts
can be defined following 2 models.
In the first model, _PRT entries reference link devices. Link devices
then describe interrupts. This allows to dynamically modify
interrupts through _SRS and _PRS objects and to choose exactly the
interrupt type (level/edge triggered, active high/low).
In the second model, interrupt numbder are described in the _PRT entry.
The interrupt type is then assumed by the OS.
The Arm BSA, sE.6 "Legacy interrupts" states that PCI legacy
interrupts must be converted to SPIs, and programmed level-sensitive,
active high. Thus any OS must configure interrupts as such and there
is no need to specify the interrupt type.
Plus it is not possible to dynamically configure PCI interrupts.
Thus remove the link device generation and use the second model
for _PRT.
Suggested-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In ACPI 6.4, s6.2.13, _PRT objects describing PCI legacy interrupts
can be defined following 2 models.
In the first model, _PRT entries reference link devices. Link devices
then describe interrupts. This allows to dynamically modify
interrupts through _SRS and _PRS objects and to choose exactly the
interrupt type (level/edge triggered, active high/low).
In the second model, interrupt numbers are described in the _PRT entry.
The interrupt type is then assumed by the OS.
AmlAddPrtEntry() currently only handles the first model. Make
changes to also handle the second model.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Parse the Pmu interrupts if a pmu compatible node is present,
and populate the MADT GicC structure accordingly.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add a macro that specifies the format for printing CM_OBJECT_ID.
This allows to print the CM_OBJECT_ID is a consistent way in the
output logs.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in
favor of a new Mpidr field. Update code in
ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c
to use the new field and call new macros GET_MPIDR_AFF0 and GET_MPIDR_AFF1
instead.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Check whenever an EDID blob is present. In case it is get the display
resolution from it. Unless PcdVideoResolutionSource indicates the
display resolution has been set already, update
PcdVideoHorizontalResolution and PcdVideoVerticalResolution accordingly.
Also add the resolution to the mode list.
This will make OVMF boot up with the display resolution configured by
QEMU, which is 1280x800 by default. The resolution can be set using the
xres and yres properties. Here is an example for FullHD:
qemu-system-x86_64 -device VGA,xres=1920,yres=1080
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3778
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1749250
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Add helper function to add a video mode to the list of modes.
Move code. Minor debug logging tweaks, no other functional
change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
All video modes in the list are 32-bit,
so drop the useless ColorDepth field.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
struct QEMU_VIDEO_MODE_DATA has all the data needed to set the video
mode, there is no need to take the extra indirection and use
struct QEMU_VIDEO_BOCHS_MODES.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
It's a UINT8 (enum) PCD telling where the PcdVideoHorizontalResolution
and PcdVideoVerticalResolution values are coming from. It can be:
0 (unset aka default from dsc file), or
1 (from PlatformConfig), or
2 (set by Video Driver).
It will be used by video drivers to avoid overriding PlatformConfig
values, or override each others values in case multiple display devices
are present.
The underlying problem this tries to solve is that the GOP protocol has
no way to indicate the preferred video mode. On physical hardware this
isn't much of a problem because using the highest resolution available
works just fine as that is typically the native display resolution
But in a virtual machine you don't want come up with a huge 4k window by
default just because the virtual vga is able to handle that. Cutting
down the video mode list isn't a great solution either as that would
also remove the modes from the platform configuration so the user
wouldn't be able to pick a resolution higher than the default any more.
So with patch drivers can use use PcdVideoHorizontalResolution and
PcdVideoVerticalResolution to indicate what the preferred display
resolution is, without overwriting the user preferences from
PlatformConfig if present.
A possible alternative approach would be to extend the GOP protocol, but
I'm not sure this is a good plan given this is mostly a problem for
virtual machines and using PCDs allows to keep this local to OvmfPkg.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
ovmf default display resolution is 800x600. This is rather small for
modern guests. qemu used 1024x768 as default for a long time and
switched the to 1280x800 recently[1] for the upcoming 7.0 release.
This patch brings ovmf in sync with the recent qemu update and likewise
switches the default to 1280x800.
[1] de72c4b7cd
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
ovmf default display resolution is 800x600. This is rather small for
modern guests. qemu used 1024x768 as default for a long time and
switched the to 1280x800 recently[1] for the upcoming 7.0 release.
This patch brings ovmf in sync with the recent qemu update and likewise
switches the default to 1280x800.
[1] de72c4b7cd
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Current, a macro CPU_TIMER_LIB_ENABLE is added to determine which timerlib
is used. BaseCpuTimerLib.inf is a better way and only fit for recent CPU.
Meanwhile, Universal Payload are only aimed to work with recent CPU.
Therefore, for Universal Payload, use the BaseCpuTimerLib by default
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>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure that "if the `MessageLength` is zero, or too large for the MM
implementation to manage, the MM implementation must update the
`MessageLength` to reflect the size of the `Data` buffer that it can
tolerate", as described by `EFI_MM_COMMUNICATION_PROTOCOL.Communicate()`
section in PI specification.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure `CommSize` represents "the size of the data buffer being passed
in" instead of the size of the data being used from data buffer, as
described by section `EFI_MM_COMMUNICATION2_PROTOCOL.Communicate()` in PI
specification.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure that return code `EFI_INVALID_PARAMETER` represents "the
`CommBuffer**` parameters do not refer to the same location in memory",
as described by `EFI_MM_COMMUNICATION2_PROTOCOL.Communicate()` section
in PI specification.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Current MM communicate2 function from ArmPkg described input arguments
`CommBufferPhysical`, `CommBufferVirtual` and `CommSize` as input only,
which mismatches with the "input and output type" as in PI specification.
This change updated function descriptions of MM communite2 to match input
argument types.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Current MM communicate2 function definition described input arguments
`CommBufferPhysical`, `CommBufferVirtual` and `CommSize` as input only,
which mismatches with the "input and output type" as in PI specification.
This change updated function descriptions of MM communite2 definition to
match input argument types.
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: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
This changes is by adding 50ms delay during voltage switching from 3.3V to
1.8V, plus adding a goto Voltage33Retry for 3.3V checking and retrying.
Change is for Enabling OS boot from SD card through UEFI payload.
Signed-off-by: Aiman Rosli <muhammad.aiman.rosli@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Update the logic handling last attempt status codes from
FmpDeviceCheckImageWithStatus() implementations to account for
cases when the function return status code is EFI_SUCCESS
(since the image was checked successfully) but the ImageUpdatable
value is not valid.
In addition the following sentence is removed from the
LastAttemptStatus parameter definition for
FmpDeviceCheckImageWithStatus() since it can lead to confusion.
The expected status code value range is sufficient to implement
the library API.
"This value will only be checked when this
function returns an error."
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
Since Cloud Hypervisor doesn't rely on the FwCfg mechanism, remove the
libraries imports when possible.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cloud Hypervisor does not emulate any 8259 PIC, therefore there's no
reason to load the corresponding driver for it.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply
need to rely on the serial I/O port to be connected as a console.
It reuses the code from Xen since it's very generic.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why
instead of relying on it as the timer UEFI services, rely on the
XenTimerDxe implementation. This is not Xen specific, as it simply uses
the local APIC timer triggering interrupts on the vector 32.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The
point is to create a target dedicated for Cloud Hypervisor rather than
trying to support both QEMU and Cloud Hypervisor on the same target.
Improvements and cleanups will be performed in follow up patches.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
There are two type variable header and their size are different,
need to use matched size when calculating offset info, otherwise
it'll destroy other variables content when patching.
Signed-off-by: Chen, Lin Z <lin.z.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Read Disk does a modification of ExtMbrStartingLba with the code MultU64x32
(ExtMbrStartingLba, BlockSize) Error detection to see if ExtMbrStartingLBA
has a value of 0. This is invalid as LBA 0 = MBR. After modification, the
next time ExtMbrStartingLba is in this function if ExtMbrStartingLba is set
to 0 in the MBR it never passes the while/do evaluation It is multiplied by
0 by read disk , set to 0 by an invalid MBR and goes back to evaluation
This condition will also cause Ws19 and WS22 to hang, however Microsoft has
developed a hotfix patch that will be released in 2022
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Craig Edwards <craig.edwards@dell.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Before trying to access parent root port to check ARI capabilities,
enumerator should see if Endpoint device is not Root Complex integrated
to avoid undefined parent register accesses.
Signed-off-by: Damian Bassa <damian.bassa@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
gcc-11 (fedora 35):
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c: In function ?UsbIoBulkTransfer?:
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c:277:12: error: ?UsbHcBulkTransfer? accessing 80 bytes in a region of size 8 [-Werror=stringop-overflow=]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
For GPU passthrough support we have to initialize the console after
EfiBootManagerDispatchDeferredImages() has loaded ROMs, so call it after
this. This was the calling order before the TCG physical presence support
had to be moved and the console initialized earlier so user interaction
could be supported before processing TCG physical presence opcodes.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Shivanshu Goyal <shivanshu3@gmail.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3463
In V2: Fixed patch format and uncrustify cleanup
In V1: To follow the TCG CRB protocol specification, on every CRB TPM
command completion the TPM should return to Idle state, regardless of
the CRB Idle Bypass capability reported by the TPM device.
See: TCG PC Client Device Driver Design Principles for TPM 2.0,
Version 1.0, Rev 0.27
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3515
In V4: Fixed patch format and uncrustify cleanup
In V3: Cleaned up comments, debug prints and updated patch to use the
new debug ENUM definitions.
- Replaced EFI_D_INFO with DEBUG_INFO.
- Replaced EFI_D_VERBOSE with DEBUG_VERBOSE.
In V2: Add case to RegisterHashInterfaceLib logic
RegisterHashInterfaceLib needs to correctly handle registering the HashLib
instance supported algorithm bitmap when PcdTpm2HashMask is set to zero.
The current implementation of SyncPcrAllocationsAndPcrMask() triggers
PCR bank reallocation only based on the intersection between
TpmActivePcrBanks and PcdTpm2HashMask.
When the software HashLibBaseCryptoRouter solution is used, no PCR bank
reallocation is occurring based on the supported hashing algorithms
registered by the HashLib instances.
Need to have an additional check for the intersection between the
TpmActivePcrBanks and the PcdTcg2HashAlgorithmBitmap populated by the
HashLib instances present on the platform's BIOS.
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Currently, the serial and part number of a processor are filled with
fixed PCDs. However, they may be updated dynamically according to the
information being passed from a the pre-UEFI firmware during booting.
So, this patch is to support updating these string fields from
OemMiscLib if the PCDs are empty.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Typically, the information of the SMBIOS type 1/2/3 is fetched from an
FRU device during UEFI booting intead of fixed PCDs. Therefore, this
patch is to add more HII string fields in the OemMiscLib and support
updating these SMBIOS types with the strings provided by the OemMiscLib
if the PCDs are empty.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch removes duplicate HII string definition in the
MiscSystemManufacturer.uni.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Rename TPM_ENABLE to TPM2_ENABLE so naming is in line with the
ArmVirtPkg config option name.
Add separate TPM1_ENABLE option for TPM 1.2 support.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Split Tcg2ConfigPei.inf into two variants: Tcg12ConfigPei.inf with
TPM 1.2 support included and Tcg2ConfigPei.inf supporting TPM 2.0 only.
This allows x86 builds to choose whenever TPM 1.2 support should be
included or not by picking the one or the other inf file.
Switch x86 builds to Tcg12ConfigPei.inf, so they continue to
have TPM 1.2 support.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Drop TPM_CONFIG_ENABLE config option. Including TPM support in the
build without also including the TPM configuration menu is not useful.
Suggested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
With this in place the tpm configuration is not duplicated for each of
our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is
easier to keep them all in sync when updating the tpm configuration.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3769
Current FvLib will hit parse issue when encountering LARGE file, then
ignore latter ffs/section, thus causing required drivers not being
dispatched. Therefore, need to add support for EFI_FFS_FILE_HEADER2
and EFI_COMMON_SECTION_HEADER2 in FvLib to fix this issue.
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the inf file of the module and the main module
functionnalities and update the dsc file of the package.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenMapper files, allowing to retrieve a CmObj
from a token/CmObjId couple.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenFixer files, allowing to update the
self-token some CmObj have.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenGenerator files.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepoLib library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to
retrieve dynamic CmObjs among all CmObj (static CmObj for instance).
This patch defines the library interface of the DynamicPlatRepo.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Handle the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
id when generating an AML description of a serial port. The same
_HID/_CID as the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550
are generated.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.
FdtHwInfoParser library is an instance of a HwInfoParser
that parses a Device Tree and populates the Configuration
Manager Platform information repository.
FdtHwInfoParser library is aimed at providing a solution
for generating ACPI tables for Guest Partitions launched
by virtual machine managers (VMMs). One such use case is
Kvmtool where the Device Tree for the Guest is passed on
to the firmware by Kvmtool. The Configuration Manager for
Kvmtool firmware shall invoke the FdtHwInfoParser to parse
the Device Tree to populate the hardware information in
the Platform Info Repository. The Kvmtool Configuration
Manager can the process this information to generate the
required ACPI tables for the Guest VM.
This approach also scales well if the number of CPUs or
if the hardware configuration of the Guest partition is
varied.
FdtHwInfoParser thereby introduces 'Dynamic Tables for
Virtual Machines'.
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=3741
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
On platforms that implement PCIe, the PCIe configuration space
information must be described to a standards-based operating
system in the Memory mapped configuration space base address
Description (MCFG) table.
The PCIe information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/pci/
host-generic-pci.yaml
The FdtHwInfoParser implements a PCI configuration space Parser
that parses the platform Device Tree to create
CM_ARM_PCI_CONFIG_SPACE_INFO objects which are encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.
The platform Configuration Manager can then utilise this
information when generating the MCFG table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC Dispatcher is the top-level component that is responsible
for invoking the respective parsers for GICC, GICD, GIC MSI Frame,
GIC ITS and the GICR.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC Redistributor (GICR) structure is part of the Multiple
APIC Description Table (MADT) that enables the discovery of
GIC Redistributor base addresses by providing the Physical Base
Address of a page range containing the GIC Redistributors. More
than one GICR Structure may be presented in the MADT. The GICR
structures should only be used when describing GIC version 3 or
higher.
The GIC Redistributor information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC Redistributor Parser that
parses the platform Device Tree to create CM_ARM_GIC_REDIST_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Arm GIC v3/v4 optionally includes support for GIC Interrupt
Translation Service (ITS). The GIC ITS Structure is part of
the Multiple APIC Description Table (MADT) that describes
the GIC Interrupt Translation service to the OS.
The GIC Interrupt Translation Service information is described
in the platform Device Tree, the bindings for which can be
found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC ITS Parser that parses the
platform Device Tree to create CM_ARM_GIC_ITS_INFO objects which
are encapsulated in a Configuration Manager descriptor object and
added to the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Arm GIC version 2 systems that support Message Signalled Interrupts
implement GICv2m MSI frame(s). Each GICv2m MSI frame consists of a
4k page which includes registers to generate message signalled
interrupts to an associated GIC distributor. The frame also includes
registers to discover the set of distributor lines which may be
signalled by MSIs from that frame. A system may have multiple MSI
frames, and separate frames may be defined for secure and non-secure
access.
A MSI Frame structure is part of the Multiple APIC Description Table
(MADT) and must only be used to describe non-secure MSI frames.
The MSI Frame information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a MSI Frame Parser that parses
the platform Device Tree to create CM_ARM_GIC_MSI_FRAME_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
On ARM-based systems the Generic Interrupt Controller (GIC)
manages interrupts on the system. Each interrupt is identified
in the GIC by an interrupt identifier (INTID). ACPI GSIVs map
one to one to GIC INTIDs for peripheral interrupts, whether
shared (SPI) or private (PPI). The GIC distributor provides
the routing configuration for the interrupts.
The GIC Distributor (GICD) structure is part of the Multiple
APIC Description Table (MADT) that describes the GIC
distributor to the OS. The MADT table is a mandatory table
required for booting a standards-based operating system.
The GIC Distributor information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC Distributor Parser that
parses the platform Device Tree to create CM_ARM_GICD_INFO
object which is encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC CPU Interface (GICC) structure is part of the Multiple
APIC Description Table (MADT) that describes the interrupt model
for the platform. The MADT table is a mandatory table required
for booting a standards-based operating system.
Arm requires the GIC interrupt model, in which the logical
processors are required to have a Processor Device object in
the DSDT, and must convey each processor's GIC information to
the OS using the GICC structure.
The CPU and GIC information is described in the platform Device
Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/arm/cpus.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC CPU Interface Parser that
parses the platform Device Tree to create CM_ARM_GICC_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT and the SSDT CPU
information tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Microsoft Debug Port Table 2 (DBG2), the Serial Port Console
Redirector (SPCR) table are mandatory tables required for booting
a standards-based operating system. The DBG2 table is used by the
OS debugger while the SPCR table is used to configure the serial
terminal. Additionally, the serial ports available on a platform
for generic use also need to be described in DSDT/SSDT for an OS
to be able to use the serial ports.
The Arm Base System Architecture 1.0 specification a lists of
supported serial port hardware for Arm Platforms. This list
includes the following serial port UARTs:
- SBSA/Generic UART
- a fully 16550 compatible UART.
Along, with these the PL011 UART is the most commonly used serial
port hardware on Arm platforms.
The serial port hardware information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/serial/serial.yaml
- linux/Documentation/devicetree/bindings/serial/8250.txt
- linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
- linux/Documentation/devicetree/bindings/serial/pl011.yaml
The FdtHwInfoParser implements a Serial Port Parser that parses
the platform Device Tree to create CM_ARM_SERIAL_PORT_INFO objects
with the following IDs:
- EArmObjSerialConsolePortInfo (for use by SPCR)
- EArmObjSerialDebugPortInfo (for use by DBG2)
- EArmObjSerialPortInfo (for use as generic Serial Ports)
The Serial Port for use by SPCR is selected by parsing the Device
Tree for the '/chosen' node with the 'stdout-path' property. The
next Serial Port is selected for use as the Debug Serial Port and
the remaining serial ports are used as generic serial ports.
The CM_ARM_SERIAL_PORT_INFO objects are encapsulated in Configuration
Manager descriptor objects with the respective IDs and are added to
the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the DBG2, SPCR and the SSDT serial port tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Generic Timer Description Table (GTDT) is a mandatory table
required for booting a standards-based operating system. It
provides an OSPM with information about a system's Generic Timer
configuration. The Generic Timer (GT) is a standard timer interface
implemented on ARM processor-based systems. The GTDT provides OSPM
with information about a system's GT interrupt configurations, for
both per-processor timers, and platform (memory-mapped) timers.
The Generic Timer information is described in the platform Device
Tree. The Device Tree bindings for the Generic timers can be found
at:
- linux/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
The FdtHwInfoParser implements a Generic Timer Parser that parses
the platform Device Tree to create a CM_ARM_GENERIC_TIMER_INFO
object. The CM_ARM_GENERIC_TIMER_INFO object is encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.
The platform Configuration Manager can then utilise this information
when generating the GTDT table.
Note: The Generic Timer Parser currently does not support parsing
of memory-mapped platform timers.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Fixed ACPI Description Table (FADT) is a mandatory table
required for booting a standards-based operating system. The
FADT table has an 'ARM Boot Architecture Flags' field that is
used by an OS at boot time to determine the code path during
boot. This field is used to specify if the platform complies
with the PSCI specification. It is also used to describe the
conduit (SMC/HVC) to be used for PSCI.
The PSCI compliance information for a platform is described
in the platform Device Tree, the bindings for which can be
found at:
- linux/Documentation/devicetree/bindings/arm/psci.yaml
The FdtHwInfoParser implements a Boot Arch Parser that parses
the platform Device Tree to create a CM_ARM_BOOT_ARCH_INFO
object. The CM_ARM_BOOT_ARCH_INFO object is encapsulated in
a Configuration Manager descriptor object and added to the
platform information repository.
The platform Configuration Manager can then utilise this
information when generating the FADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration Manager
objects.
Therefore, add a set of helper functions to simplify parsing of
the platform Device Tree.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
FdtHwInfoParserLib is an instance of the HwInfoParser. The
FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration
Manager objects that describe the platform hardware.
These Configuration Manager objects are encapsulated in
Configuration Manager Object Descriptors.
Therefore, add helper functions to create and free the
Configuration Manager Object descriptors.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.
The Configuration Manager can then utilise this information
to generate ACPI tables for the platform.
Therefore, define an interface for the HwInfoParser library
class.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Co-authored-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
New SMC helper functions have been added to reduce the amount of
template code. Update ArmSmcPsciResetSystemLib and
Smbios/ProcessorSubClassDxe to use them.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add functions ArmCallSmc0/1/2/3 to do SMC calls with 0, 1, 2 or 3
arguments.
The functions return up to 3 values.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The version of lldb shipping with macOS Big Sur is lldb-1205.0.27.3, and
it uses python3. Update lldbefi.py to work with it, including removing
the unused 'commands' import and fixing the print statements.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Prefer the e820 map provided via qemu firmware config interface
for memory detection. Use rtc cmos only as fallback, which should
be rarely needed these days as qemu supports etc/e820 since 2013.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify
whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above
4G) or scan only.
Also add a lowmem parameter so ScanOrAdd64BitE820Ram
can report the memory size below 4G.
This allows a more flexible usage of ScanOrAdd64BitE820Ram,
a followup patch will use it for all memory detection.
No functional change.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
When a CmObjDesc contains multiple objects, only the first one is
parsed as the buffer doesn't progress. Fix this.
Also check that the whole buffer has been parsed with an asset.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Introduce the following CmObj in the ArmNameSpaceObjects:
- CM_ARM_PCI_ADDRESS_MAP_INFO
- CM_ARM_PCI_INTERRUPT_MAP_INFO
These objects allow to describe address range mapping
of Pci busses and interrupt mapping of Pci devices.
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This function allows to add a node as the last node of a parent node
in an AML tree. For instance,
ASL code corresponding to NewNode:
Name (_UID, 0)
ASL code corresponding to ParentNode:
Device (PCI0) {
Name(_HID, EISAID("PNP0A08"))
}
"AmlAttachNode (ParentNode, NewNode)" will result in:
ASL code:
Device (PCI0) {
Name(_HID, EISAID("PNP0A08"))
Name (_UID, 0)
}
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
_PRT entries can describe interrupt mapping for Pci devices. The
object is described in ACPI 6.4 s6.2.13 "_PRT (PCI Routing Table)".
Add AmlCodeGenPrtEntry() helper function to add _PRT entries
to an existing _PRT object.
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add AmlCodeGenNameResourceTemplate() to generate code for a
ResourceTemplate().
AmlCodeGenNameResourceTemplate ("REST", ParentNode, NewObjectNode) is
equivalent of the following ASL code:
Name(REST, ResourceTemplate () {})
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add AmlCodeGenNamePackage() to generate code for a Package().
AmlCodeGenNamePackage ("PACK", ParentNode, NewObjectNode) is
equivalent of the following ASL code:
Name(PACK, Package () {})
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add helper functions to generate AML Resource Data describing memory
ranges. Memory ranges can be one, double or four words long. They
can be of 'normal', IO or bus number memory type. The following
APIs are exposed:
- AmlCodeGenRdDWordIo ()
- AmlCodeGenRdDWordMemory ()
- AmlCodeGenRdWordBusNumber ()
- AmlCodeGenRdQWordMemory ()
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add virtio-mmio support (VirtioMmioDeviceLib and VirtioFdtDxe).
With this patch added and a new enough qemu version (6.2+) edk2
will detect virtio-mmio devices, so it is possible to boot from
storage (virtio-blk, virtio-scsi) or network (virtio-net).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
FdtClient is unhappy without a device tree, so add an empty fdt
which we can use in case etc/fdt is not present in fw_cfg.
On ARM machines a device tree is mandatory for hardware detection,
that's why FdtClient fails hard.
On microvm the device tree is only used to detect virtio-mmio devices
(this patch series) and the pcie host (future series). So edk2 can
continue with limited functionality in case no device tree is present:
no storage, no network, but serial console and direct kernel boot
works.
qemu release 6.2 & newer will provide a device tree for microvm.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Building grub.efi for AmdSev is difficult because it depends on patches
not yet merged to upstream grub. So shortcut the grub build by simply
creating an empty grub.efi file. That allows to at least build-test the
AmdSev variant.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Dov Murik <dovmurik@linux.ibm.com>
Move SettingsManager and PlatformBuilder classes to PlatformBuildLib.py
file, keep only CommonPlatform class in PlatformBuild.py. Allows
reusing these classes for other builds. Pure code motion, no functional
change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Fixes build failure:
build.py...
/home/kraxel/projects/edk2/OvmfPkg/Bhyve/BhyveX64.dsc(...): error 1001: Module type [SEC] is not supported by library instance [/home/kraxel/projects/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf]
consumed by [/home/kraxel/projects/edk2/OvmfPkg/Sec/SecMain.inf]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3625
DxeTpm2MeasureBootLib supports TPM2 based measure boot. After
CcMeasurementProtocol is introduced, CC based measure boot needs to
be supported in DxeTpm2MeasureBootLib as well.
There are 2 major changes in this commit.
1. A platform should have only one RTS/RTR. Only one of (virtual)TPM1.2,
(virtual)TPM2.0 and CC MR exists. Then only one TCG_SERVICE_PROTOCOL,
TCG2_PROTOCOL, CC_MEASUREMENT_PROTOCOL is exposed. In this library when
do measure boot only one of TCG2_PROTOCOL / CC_MEASUREMENT_PROTOCOL
will be called. MEASURE_BOOT_PROTOCOLS is defined to store the instances
of TCG2 protocol and CC Measurement protocol.
2. CcEvent is similar to Tcg2Event except the MrIndex and PcrIndex.
So in the code Tcg2Event will be first created and intialized. If
CcMeasurementProtocol is called to do the measure boot, then CcEvent
points to Tcg2Event and the MrIndex is adjusted.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
In FvbInitialize Function,
PcdFlashNvStorageVariableBase64 PcdFlashNvStorageFtwWorkingBase
PcdFlashNvStorageFtwSpareBase will not exceed 0x100000000,
Due to truncation and variable type limitations.
That leads to the NV variable cannot be saved to the memory above 4G.
Modify as follows:
1.Remove the forced type conversion of UINT32.
2.Use UINT64 type variables.
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
commit 202fb22be6 "OvmfPkg/SecMain: validate the memory used for
decompressing Fv" broke building OvmfXen with:
edk2/OvmfPkg/OvmfXen.dsc(...): error 1001: Module type [SEC] is not
supported by library instancer
[edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf]
consumed by [edk2/OvmfPkg/Sec/SecMain.inf]
The above commit added a reference to MemEncryptSevLib into SecMain.inf,
but OvmfXen.dsc doesn't have a MemEncryptSevLib entry for SEC. Add one
like OvmfPkgX64.dsc has.
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: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Don't make the package Qemu centric so that we can introduce some
alternative support for other VMMs not using the fw_cfg mechanism.
This patch is purely about renaming existing files with no functional
change.
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Move the generic entry point part out of Qemu.c to anticipate the
addition of new ways of retrieving the SMBIOS table.
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
During AP bringup, just after switching to long mode, APs will do some
cpuid calls to verify that the extended topology leaf (0xB) is available
so they can fetch their x2 APIC IDs from it. In the case of SEV-ES,
these cpuid instructions must be handled by direct use of the GHCB MSR
protocol to fetch the values from the hypervisor, since a #VC handler
is not yet available due to the AP's stack not being set up yet.
For SEV-SNP, rather than relying on the GHCB MSR protocol, it is
expected that these values would be obtained from the SEV-SNP CPUID
table instead. The actual x2 APIC ID (and 8-bit APIC IDs) would still
be fetched from hypervisor using the GHCB MSR protocol however, so
introducing support for the SEV-SNP CPUID table in that part of the AP
bring-up code would only be to handle the checks/validation of the
extended topology leaf.
Rather than introducing all the added complexity needed to handle these
checks via the CPUID table, instead let the BSP do the check in advance,
since it can make use of the #VC handler to avoid the need to scan the
SNP CPUID table directly, and add a flag in ExchangeInfo to communicate
the result of this check to APs.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
Suggested-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
When SEV-SNP is active, a memory region mapped encrypted in the page
table must be validated before access. There are two approaches that
can be taken to validate the system RAM detected during the PEI phase:
1) Validate on-demand
OR
2) Validate before access
On-demand
=========
If memory is not validated before access, it will cause a #VC
exception with the page-not-validated error code. The VC exception
handler can perform the validation steps.
The pages that have been validated will need to be tracked to avoid
the double validation scenarios. The range of memory that has not
been validated will need to be communicated to the OS through the
recently introduced unaccepted memory type
https://github.com/microsoft/mu_basecore/pull/66, so that OS can
validate those ranges before using them.
Validate before access
======================
Since the PEI phase detects all the available system RAM, use the
MemEncryptSevSnpValidateSystemRam() function to pre-validate the
system RAM in the PEI phase.
For now, choose option 2 due to the dependency and the complexity
of the on-demand validation.
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The initial page built during the SEC phase is used by the
MemEncryptSevSnpValidateSystemRam() for the system RAM validation. The
page validation process requires using the PVALIDATE instruction; the
instruction accepts a virtual address of the memory region that needs
to be validated. If hardware encounters a page table walk failure (due
to page-not-present) then it raises #GP.
The initial page table built in SEC phase address up to 4GB. Add an
internal function to extend the page table to cover > 4GB. The function
builds 1GB entries in the page table for access > 4GB. This will provide
the support to call PVALIDATE instruction for the virtual address >
4GB in PEI phase.
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Virtual Machine Privilege Level (VMPL) feature in the SEV-SNP
architecture allows a guest VM to divide its address space into four
levels. The level can be used to provide the hardware isolated
abstraction layers with a VM. The VMPL0 is the highest privilege, and
VMPL3 is the least privilege. Certain operations must be done by the
VMPL0 software, such as:
* Validate or invalidate memory range (PVALIDATE instruction)
* Allocate VMSA page (RMPADJUST instruction when VMSA=1)
The initial SEV-SNP support assumes that the guest is running on VMPL0.
Let's add function in the MemEncryptSevLib that can be used for checking
whether guest is booted under the VMPL0.
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Many of the integrity guarantees of SEV-SNP are enforced through the
Reverse Map Table (RMP). Each RMP entry contains the GPA at which a
particular page of DRAM should be mapped. The guest can request the
hypervisor to add pages in the RMP table via the Page State Change VMGEXIT
defined in the GHCB specification section 2.5.1 and 4.1.6. Inside each RMP
entry is a Validated flag; this flag is automatically cleared to 0 by the
CPU hardware when a new RMP entry is created for a guest. Each VM page
can be either validated or invalidated, as indicated by the Validated
flag in the RMP entry. Memory access to a private page that is not
validated generates a #VC. A VM can use the PVALIDATE instruction to
validate the private page before using it.
During the guest creation, the boot ROM memory is pre-validated by the
AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called
during the SEC and PEI phase to validate the detected system RAM.
One of the fields in the Page State Change NAE is the RMP page size. The
page size input parameter indicates that either a 4KB or 2MB page should
be used while adding the RMP entry. During the validation, when possible,
the MemEncryptSevSnpValidateSystemRam() will use the 2MB entry. A
hypervisor backing the memory may choose to use the different page size
in the RMP entry. In those cases, the PVALIDATE instruction should return
SIZEMISMATCH. If a SIZEMISMATCH is detected, then validate all 512-pages
constituting a 2MB region.
Upon completion, the PVALIDATE instruction sets the rFLAGS.CF to 0 if
instruction changed the RMP entry and to 1 if the instruction did not
change the RMP entry. The rFlags.CF will be 1 only when a memory region
is already validated. We should not double validate a memory
as it could lead to a security compromise. If double validation is
detected, terminate the boot.
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Commit 85b8eac59b added support to ensure
that MMIO is only performed against the un-encrypted memory. If MMIO
is performed against encrypted memory, a #GP is raised.
The AmdSevDxe uses the functions provided by the MemEncryptSevLib to
clear the memory encryption mask from the page table. If the
MemEncryptSevLib is extended to include VmgExitLib then depedency
chain will look like this:
OvmfPkg/AmdSevDxe/AmdSevDxe.inf
-----> MemEncryptSevLib class
-----> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance
-----> VmgExitLib class
-----> "OvmfPkg/VmgExitLib" instance
-----> LocalApicLib class
-----> "UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf" instance
-----> TimerLib class
-----> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance
-----> PciLib class
-----> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance
-----> PciExpressLib class
-----> "MdePkg/BasePciExpressLib/BasePciExpressLib.inf" instance
The LocalApicLib provides a constructor that gets called before the
AmdSevDxe can clear the memory encryption mask from the MMIO regions.
When running under the Q35 machine type, the call chain looks like this:
AcpiTimerLibConstructor () [AcpiTimerLib]
PciRead32 () [DxePciLibI440FxQ35]
PciExpressRead32 () [PciExpressLib]
The PciExpressRead32 () reads the MMIO region. The MMIO regions are not
yet mapped un-encrypted, so the check introduced in the commit
85b8eac59b raises a #GP.
The AmdSevDxe driver does not require the access to the extended PCI
config space. Accessing a normal PCI config space, via IO port should be
sufficent. Use the module-scope override to make the AmdSevDxe use the
BasePciLib instead of BasePciExpressLib so that PciRead32 () uses the
IO ports instead of the extended config space.
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
SEV-SNP firmware allows a special guest page to be populated with
guest CPUID values so that they can be validated against supported
host features before being loaded into encrypted guest memory to be
used instead of hypervisor-provided values [1].
Add handling for this in the CPUID #VC handler and use it whenever
SEV-SNP is enabled. To do so, existing CPUID handling via VmgExit is
moved to a helper, GetCpuidHyp(), and a new helper that uses the CPUID
page to do the lookup, GetCpuidFw(), is used instead when SNP is
enabled. For cases where SNP CPUID lookups still rely on fetching
specific CPUID fields from hypervisor, GetCpuidHyp() is used there as
well.
[1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
An SEV-SNP guest requires that private memory (aka pages mapped encrypted)
must be validated before being accessed.
The validation process consist of the following sequence:
1) Set the memory encryption attribute in the page table (aka C-bit).
Note: If the processor is in non-PAE mode, then all the memory accesses
are considered private.
2) Add the memory range as private in the RMP table. This can be performed
using the Page State Change VMGEXIT defined in the GHCB specification.
3) Use the PVALIDATE instruction to set the Validated Bit in the RMP table.
During the guest creation time, the VMM encrypts the OVMF_CODE.fd using
the SEV-SNP firmware provided LAUNCH_UPDATE_DATA command. In addition to
encrypting the content, the command also validates the memory region.
This allows us to execute the code without going through the validation
sequence.
During execution, the reset vector need to access some data pages
(such as page tables, SevESWorkarea, Sec stack). The data pages are
accessed as private memory. The data pages are not part of the
OVMF_CODE.fd, so they were not validated during the guest creation.
There are two approaches we can take to validate the data pages before
the access:
a) Enhance the OVMF reset vector code to validate the pages as described
above (go through step 2 - 3).
OR
b) Validate the pages during the guest creation time. The SEV firmware
provides a command which can be used by the VMM to validate the pages
without affecting the measurement of the launch.
Approach #b seems much simpler; it does not require any changes to the
OVMF reset vector code.
Update the OVMF metadata with the list of regions that must be
pre-validated by the VMM before the boot.
Cc: Michael Roth <michael.roth@amd.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
When use the UsbHcAllocMemFromBlock() and UsbHcFreeMem() to allocate
memory and free memory for the UHC, it should use the corresponding host
address but not the pci bus address.
Signed-off-by: jdzhang <jdzhang@zd-tech.com.cn>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3754
1. DxeCore will use ModuleInfo to install LoadedImage protocol for DxeCore.
2. DxeIpl will create the ModuleInfo of UniversalPayload. and
UniversalPayload will create the ModuleInfo of DxeCore.
3. UniversalPayload should skip the ModuleInfo from the DxeIpl to avoid
the mismatched ModuleInfo for DxeCore.
Changes:
1. Use function IsHobNeed to check if the HOB should be added
2. Add the ModuleInfo check logic in IsHobNeed function
Signed-off-by: Guomin Jiang <guomin.jiang@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>
Add a Macro to enable performance measurement feature.
For any platform that uses UniversalPayload, we assume it supports
BaseCpuTimerLib and use it to align timerlib to get more accurate
performance result.
Reviewed-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>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Current, the SystemMemoryUefiRegionSize is 32M, which means in universal
payload entry, we can at most use 32M heap.
However, this can't meet the memory requirment for 5 level page table.
In UefiPayloadPkg\UefiPayloadEntry\X64\VirtualMemory.c, we assume the
Physical Address at most has 52 bits. Using 1G table support, with 52 bits
Physical Address, to build page table, we need one page to hold 16 PML5
entries, each PML5 entry points to one page containing 512 PML4 entries.
One PML4 entry points to one page containing 512 PML3 entries. Each PML3
entries will point to 1G memory space. Totally 8209 pages are needed,
which is around 32M bytes.
Therefore, increase SystemMemoryUefiRegionSize from 32M to 64M to support
5 level page tables.
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>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The patch removes the dep on PcdUse5LevelPageTable.
Now the payload inherits the 5-level paging setting from
bootloader in IA-32e mode and uses 4-level paging in
legacy protected mode.
This fix the potential issue when bootloader enables 5-level paging
but 64bit payload sets 4-level page table to CR3 resulting CPU
exception because PcdUse5LevelPageTable is FALSE.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3748
Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.
An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application host in this repository:
https://dev.azure.com/projectmu/Uncrustify/
Note that the Uncrustify application outputs the commit ID that the
application was built from when given the --version parameter.
This ID can be mapped to the version specified in the Uncrustify CI
plugin external dependency file (uncrustify_ext_dep.yaml) such as
73.0.3 by visiting the Uncrustify edk2 fork release pipeline page
which associates the NuGet package version with the commit ID it was
built from:
https://dev.azure.com/projectmu/Uncrustify/_build
The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.
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: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2986
Improve the performance of EccCheck by using a temp file
instead of stdout to capture the results of the git diff
commands. If a large patch set is passed into EccCheck,
using stdout could be slow and also added the large diff
content to the build log that is redundant information.
A second performance improvement is to filter the
modified directories to remove duplicate directories.
Complex libraries and modules that have subdirectories
with sources would be scanned twice if there were source
changes in both the main directory and subdirectories.
Filter out the subdirectories from the modified directory
list when this case is detected.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2957
1. Allocate performance data table at EndOfDxe and then lock the varible
which store the table address at EndOfDxe.
2. Enlarge PCD gEfiMdeModulePkgTokenSpaceGuid.PcdExtFpdtBootRecordPadSize
from 0x20000 to 0x30000 in order to hold the Delta performance data
between EndOfDxe and ReadyToBoot.
3. SMM performance data is collected by DXE modules through SMM communication
at ReadyToBoot before.
Now to do SMM communication twice, one for allocating the performance
size at EndOfDxe, another is at ReadyToBoot to get SMM performance data.
4. Make SmmCorePerformanceLib rather than FirmwarePerformanceSmm to communicate
with DxeCorePerformanceLib for SMM performance data and size.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
In order to support secure boot with authenticated type variable store
and non secure boot with normal type variable store, add one flag to
switch them.
User can append '-D VPD_AUTHENTICATED_VARIABLE_STORE' to build command
to enable authenticated type varaible store.
Also, user can add 'VPD_AUTHENTICATED_VARIABLE_STORE = TRUE/FALSE' to the
defines section of Dsc file to switch authenticated/normal type variable
store.
VPD_AUTHENTICATED_VARIABLE_STORE is a new reserved key word for this function.
Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Enhance RelocateCapsuleToRam() to skip creation of the Capsule on Disk
file name capsule if PcdSupportUpdateCapsuleReset feature is not enabled.
This avoids an EFI_UNSUPPORTED return status from UpdateCapsule() when the
file name capsule is encountered and PcdSupportUpdateCapsuleReset is FALSE.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Signed-off-by: Bob Morgan <bobm@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3578 (https://bugzilla.tianocore.org/show_bug.cgi?id=3579)
Since the Common Memory Device (formerly Memory Aggregator Device) was
introduced in ACPI 5.0, the edk2 type values have not matched the
values defined in the ACPI specification.
Fix this discrepancy by aligning the code to match the specification.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add a comment to clarify that in Acpiview the ItemPtr is not set until
after the FieldValidator has been called.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
The current UEFI implementation of HTTPS during its TLS configuration
uses
EFI_TLS_VERIFY_FLAG_NO_WILDCARDS for host name verification. As per the
spec
this flag does is "to disable the match of any wildcards in the host
name". So,
certificates which are issued with wildcards(*.dm.corp.net etc) in it
will fail
the TLS host name matching. On the other hand,
EFI_TLS_VERIFY_FLAG_NONE(misnomer) means "no additional flags set for
hostname
validation. Wildcards are supported and they match only in the left-most
label."
this behavior/definition is coming from openssl's X509_check_host() api
https://www.openssl.org/docs/man1.1.0/man3/X509_check_host.html
Without EFI_TLS_VERIFY_FLAG_NONE any UEFI application using certificates
issued
with wildcards in them would fail to match while trying to communicate
with
HTTPS endpoint.
BugZilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3691
Signed-off-by: Vineel Kovvuri <vineelko@microsoft.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2673
M mean that Measured Boot, V mean that Verified Boot.
The FvReport do below:
1. Do nothing if neither M nor V
2. Allocate pages to save the firmware volume and use it to install
firmware info Ppi
3. Install PreHashFv Ppi if the FV need measurement.
4. Verify the Hash if the FV need verification
Notes:
1. The component is used to verify the FV or measure the FV
2. Copy action is just for security purpose but not main purpose.
3. If you use this component, Doesn't need to copy in other compoent
which result time consumption.
Signed-off-by: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
PCH SMM module would install SMM SW dispatch2 protocol.
And it supports to register SMI handlers based on SMI APM
interrupt from the bootloader information gSmmRegisterInfoGuid.
It is possible to extend bootloader HOB to pass other information
to support more SMI sources.
If this module is not required by bootloader for some reason, the
bootloader could skip this HOB or build a HOB without EOS info.
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: Ray Ni <ray.ni@intel.com>
Reviewed-by: Benjamin You <benjamin.you@intel.com>
This FVB module is used to initialize NV variable region
and provide SMM FVB protocol to read/write SPI variable region.
This module consume HOB gNvVariableInfoGuid and depends on
FlashDeviceLib for the actual SPI device operate.
During FVB initialization, it will initialize the variable region
if the variable region is not valid. And it support to write initial
variable data from FFS file if it is found.
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: Ray Ni <ray.ni@intel.com>
Reviewed-by: Benjamin You <benjamin.you@intel.com>
This module is only used for SMM S3 support for the bootloader that
doesn't support SMM.
The payload would save SMM rebase info to SMM communication area in
normal boot and expect the bootloader in S3 path to rebase the SMM
and trigger SMI by writing 0xB2 port with the given value from SMM
communication area. The payload SMM handler would get chance to
restore some registers in S3 path.
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: Ray Ni <ray.ni@intel.com>
Reviewed-by: Benjamin You <benjamin.you@intel.com>
This module consumes SMM Registers HOB (SMI_GBL_EN and SMI_APM_EN) to
install SMM control 2 protocol gEfiSmmControl2ProtocolGuid.
The protocol activate() would set SMI_GBL_EN and SMI_APM_EN and trigger
SMI by writing to IO port 0xB3 and 0xB2.
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: Ray Ni <ray.ni@intel.com>
Reviewed-by: Benjamin You <benjamin.you@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.
Note: Intel TDX is only available on X64, so the Tdx related changes are
in X64 path. In IA32 path, there may be null stub to make the build
success.
This patch includes below major changes.
1. Ia32/IntelTdx.asm
IntelTdx.asm includes below routines used in ResetVector
- IsTdx
Check if the running system is Tdx guest.
- InitTdxWorkarea
It initialize the TDX_WORK_AREA. Because it is called by both BSP and
APs and to avoid the race condition, only BSP can initialize the
WORK_AREA. AP will wait until the field of TDX_WORK_AREA_PGTBL_READY
is set.
- ReloadFlat32
After reset all CPUs in TDX are initialized to 32-bit protected mode.
But GDT register is not set. So this routine loads the GDT then jump
to Flat 32 protected mode again.
- InitTdx
This routine wrap above 3 routines together to do Tdx initialization
in ResetVector phase.
- IsTdxEnabled
It is a OneTimeCall to probe if TDX is enabled by checking the
CC_WORK_AREA.
- CheckTdxFeaturesBeforeBuildPagetables
This routine is called to check if it is Non-TDX guest, TDX-Bsp or
TDX-APs. Because in TDX guest all the initialization is done by BSP
(including the page tables). APs should not build the tables.
- TdxPostBuildPageTables
It is called after Page Tables are built by BSP.
byte[TDX_WORK_AREA_PGTBL_READY] is set by BSP to indicate APs can
leave spin and go.
2. Ia32/PageTables64.asm
As described above only the TDX BSP build the page tables. So
PageTables64.asm is updated to make sure only TDX BSP build the
PageTables. TDX APs will skip the page table building and set Cr3
directly.
3. Ia16/ResetVectorVtf0.asm
In Tdx all CPUs "reset" to run on 32-bit protected mode with flat
descriptor (paging disabled). But in Non-Td guest the initial state of
CPUs is 16-bit real mode. To resolve this conflict, BITS 16/32 is used
in the ResetVectorVtf0.asm. It checks the 32-bit protected mode or 16-bit
real mode, then jump to the corresponding entry point.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.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>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429
In TDX when host VMM creates a new guest TD, some initial set of
TD-private pages are added using the TDH.MEM.PAGE.ADD function. These
pages typically contain Virtual BIOS code and data along with some clear
pages for stacks and heap. In the meanwhile, some configuration data
need be measured by host VMM. Tdx Metadata is designed for this purpose
to indicate host VMM how to do the above tasks.
More detailed information of Metadata is in [TDVF] Section 11.
Tdx Metadata describes the information about the image for VMM use.
For example, the base address and length of the TdHob, Bfv, Cfv, etc.
The offset of the Metadata is stored in a GUID-ed structure which is
appended in the GUID-ed chain from a fixed GPA (0xffffffd0).
In this commit there are 2 new definitions of BFV & CFV.
Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known
as the Boot Firmware Volume (BFV). The FV format is defined in the
UEFI Platform Initialization (PI) spec. BFV includes all TDVF
components required during boot.
TDVF also include a configuration firmware volume (CFV) that is
separated from the BFV. The reason is because the CFV is measured in
RTMR, while the BFV is measured in MRTD.
In practice BFV is the code part of Ovmf image (OVMF_CODE.fd). CFV is
the vars part of Ovmf image (OVMF_VARS.fd).
Since AMD SEV has already defined some SEV specific memory region in
MEMFD. TDX re-uses some of the memory regions defined by SEV.
- MailBox : PcdOvmfSecGhcbBackupBase|PcdOvmfSecGhcbBackupSize
- TdHob : PcdOvmfSecGhcbBase|PcdOvmfSecGhcbSize
[TDVF] https://software.intel.com/content/dam/develop/external/us/en/
documents/tdx-virtual-firmware-design-guide-rev-1.pdf
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Previously WORK_AREA_GUEST_TYPE was cleared in SetCr3ForPageTables64.
This is workable for Legacy guest and SEV guest. But it doesn't work
after Intel TDX is introduced. It is because all TDX CPUs (BSP and APs)
start to run from 0xfffffff0, thus WORK_AREA_GUEST_TYPE will be cleared
multi-times if it is TDX guest. So the clearance of WORK_AREA_GUEST_TYPE
is moved to Main16 entry point in Main.asm.
Note: WORK_AREA_GUEST_TYPE is only defined for ARCH_X64.
For Intel TDX, its corresponding entry point is Main32 (which will be
introduced in next commit in this patch-set). WORK_AREA_GUEST_TYPE will
be cleared there.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.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>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
LinuxBoot is a firmware that replaces specific firmware functionality
like the UEFI DXE phase with a Linux kernel and runtime. It is built-in
UEFI image like an application, which is executed at the end of DXE
phase.
To achieve the LinuxBoot boot flow "SEC->PEI->DXE->BDS->LinuxBoot",
today we use the common well-known GUID of UEFI Shell for LinuxBoot
payload, so LinuxBoot developers can effortlessly find the UEFI Shell
Application and replace it with the LinuxBoot payload without
recompiling platform EDK2 (There might be an issue with a few systems
that don't have a UEFI Shell). Also, we have a hard requirement to force
the BDS to boot into the LinuxBoot as it is essentially required that
only the LinuxBoot boot option is permissible and UEFI is an
intermediate bootstrap phase. Considering all the above, it is
reasonable to just have a new GUID for LinuxBoot and require a LinuxBoot
specific BDS implementation. In addition, with making the BDS
implementation simpler, we can reduce many DXE drivers which we think it
is not necessary for LinuxBoot booting.
This patch adds a new PlatformBootManagerLib implementation which
registers only the gArmTokenSpaceGuid.PcdLinuxBootFileGuid for LinuxBoot
payload as an active boot option. It allows BDS to jump to the LinuxBoot
quickly by skipping the UiApp and UEFI Shell.
The PlatformBootManagerLib library derived from
ArmPkg/Library/PlatformBootManagerLib.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Acked-by: Moritz Fischer <moritzf@google.com>
Building the DynamicTablesPkg with the additional
-Wpointer-arith flag triggers the following error:
"pointer of type ‘void *’ used in arithmetic
[-Werror=pointer-arith]"
Cast the void pointer to fix the error.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In the success case we should return EFI_SUCCESS rather than returning
a potentially unitialized value of Status.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Moritz Fischer <moritzf@google.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3634
The memory allocated through "PeiAllocatePool" is located in HOB, and
in DXE phase, the HOB will be migrated to a different location.
After the migration, the data stored in the HOB stays the same, but the
address of pointer to the memory(such as the pointers in ACPI_CPU_DATA
structure) changes, which may cause "PiSmmCpuDxeSmm" driver can't find
the memory(the pointers in ACPI_CPU_DATA structure) that allocated in
"PeiRegisterCpuFeaturesLib", so use "PeiAllocatePages" to allocate
memory instead.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
V2: Fix more header files on #ifdef variable
ECC reported some issues on UefiPayloadPkg, this patch fixed
most of them except several files including ElfLib\Elf32.h,
coreboot.h, CbParseLib.c, etc.
It also removed unused functions in ResetSystemLib and Hob.c.
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: Maurice Ma <maurice.ma@intel.com>
Currently, the flag "-fpie" is passed for all builds with a GCC
family toolchain, including CLANGPDB. CLANGPDB however does not
support this flag as it generates PE/COFF files directly.
As the flag is mostly required for ARM-specific self-relocation, drop
it for other architectures and document the limitation to enable e.g.
X64 CLANGPDB builds of StandaloneMmCore.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Acked-by: Shi Steven <steven.shi@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3680
This patch fixes the following issue:
The global variable gHandleList is a linked list.
This list is locked when a entry is added or removed from the list,
but there is no lock when iterating this list in function
CoreValidateHandle().
It can lead to "Handle.c (76): CR has Bad Signature" assertion if the
iterated entry in the list is just removed by other task during iterating.
Currently some caller functions of CoreValidateHandle() have
CoreAcquireProtocolLock(), but some caller functions of
CoreValidateHandle() do not CoreAcquireProtocolLock().
Add CoreAcquireProtocolLock() always when CoreValidateHandle() is called,
Also, A lock check is added in the CoreValidateHandle().
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hua Ma <hua.ma@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Add correct content to the 'SdDxeExtra.uni' file.
Include 'EmmcDxeExtra.uni' and 'SdDxeExtra.uni' files to their
appropriate INF files.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Current UefiPayloadPkg can suport PCI root bridge info HOB
provided by bootloader. For UniversalPayload, bootloader can
directly provide this HOB for payload consumption. However,
for legacy UEFI payload, it is required to migrate the HOB
information from bootloader HOB space to UEFI payload HOB
space. This patch added the missing part for the bootloader
ParseLib in order to support both legacy and universal UEFI
payload.
This patch was tested on Slim Bootloader with latest UEFI
payload, and it worked as expected.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Currently the realpath is used when parse modules, which shows the
path with a drive letter in build log. In Windows 'subst' comand is
used to associates a path with a drive letter, when use the mapped
drive letter for build, with realpath function the build log will
have different disk letter info which will cause confusion. In this
situation, if use adspath function to show the path info, it will keep
same letter with the mapped drive letter, which avoids confusion.
This patch modifies the realpath to abspath.
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 patch adds entry into QueryTable.c for ProcessorUpgradeSocketLGA4677
from SMBIOS 3.5.0.
It also adds entries into QueryTable.c for ProcessorUpgradeSocketLGA4189
and ProcessorUpgradeSocketLGA1200 from SMBIOS 3.4.0.
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
This patch adds ProcessorUpgradeSocketLGA4677 definition into Smbios.h
from SMBIOS 3.5.0.
It also adds ProcessorUpgradeSocketLGA4189 and ProcessorUpgradeSocketLGA1200
definitions into from SMBIOS 3.4.0.
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In the GIC interrupt model, logical processors are required to
have a Processor Device object in the DSDT and must convey each
processor's GIC information to the OS using the GICC structure.
Additionally, _LPI objects may be needed as they provide a method
to describe Low Power Idle states that defines the local power
states for each node in a hierarchical processor topology.
Therefore, add support to generate the CPU topology and the LPI
state information in an SSDT table.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Introduce the CM_ARM_LPI_INFO CmObj in the ArmNameSpaceObjects.
This allows to describe LPI state information, as described in
ACPI 6.4, s8.4.4.3 "_LPI (Low Power Idle States)".
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlAddLpiState() to generates AML code to add an _LPI state
to an _LPI object created using AmlCreateLpiNode().
AmlAddLpiState increments the count of LPI states in the LPI
node by one, and adds the following package:
Package() {
MinResidency,
WorstCaseWakeLatency,
Flags,
ArchFlags,
ResCntFreq,
EnableParentState,
(GenericRegisterDescriptor != NULL) ? // Entry method. If a
ResourceTemplate(GenericRegisterDescriptor) : // Register is given,
Integer, // use it. Use the
// Integer otherwise
ResourceTemplate() { // NULL Residency
Register (SystemMemory, 0, 0, 0, 0) // Counter
},
ResourceTemplate() { // NULL Usage Counter
Register (SystemMemory, 0, 0, 0, 0)
},
"" // NULL State Name
},
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
_LPI object provides a method to describe Low Power Idle
states that define the local power states for each node
in a hierarchical processor topology.
Therefore, add AmlCreateLpiNode() to generate code for a
_LPI object.
AmlCreateLpiNode ("_LPI", 0, 1, ParentNode, &LpiNode) is
equivalent of the following ASL code:
Name (_LPI, Package (
0, // Revision
1, // LevelId
0 // Count
))
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlCodeGenMethodRetNameString() to generate AML code to create
a Method returning a NameString (NS).
AmlCodeGenMethodRetNameString (
"MET0", "_CRS", 1, TRUE, 3, ParentNode, NewObjectNode
);
is equivalent of the following ASL code:
Method(MET0, 1, Serialized, 3) {
Return (_CRS)
}
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlCodeGenReturnNameString() to generate AML code for a
Return object node, returning the object as a NameString.
AmlCodeGenReturn ("NAM1", ParentNode, NewObjectNode) is
equivalent of the following ASL code:
Return(NAM1)
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlCodeGenMethod() to generate code for a control method.
AmlCodeGenMethod ("MET0", 1, TRUE, 3, ParentNode, NewObjectNode)
is equivalent of the following ASL code:
Method(MET0, 1, Serialized, 3) {}
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
ASL provides a ResourceTemplate macro that creates a Buffer in which
resource descriptor macros can be listed. The ResourceTemplate macro
automatically generates an End descriptor and calculates the checksum
for the resource template.
Therefore, add AmlCodeGenResourceTemplate() to generate AML code for
the ResourceTemplate() macro. This function generates a Buffer node
with an EndTag resource data descriptor, which is similar to the ASL
ResourceTemplate() macro.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Some AML object have a PkgLen which indicates the size of the
AML object. The package length can be encoded in 1 to 4 bytes.
The bytes used to encode the PkgLen is itself counted in the
PkgLen value. So, if an AML object's size increments/decrements,
the number of bytes used to encode the PkgLen value can itself
increment/decrement.
Therefore, a helper function AmlComputePkgLength() is introduced
to simply computation of the PkgLen.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlCodeGenPackage() to generate AML code for declaring
a Package() object. This function generates an empty package
node. New elements can then be added to the package's variable
argument list.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add a helper function AmlCodeGenEndTag() to generate AML Resource Data
EndTag. The EndTag resource data is automatically generated by the ASL
compiler at the end of a list of resource data elements. Therefore, an
equivalent function is not present in ASL.
However, AmlCodeGenEndTag() is useful when generating AML code for the
ResourceTemplate() macro.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlCodeGenRegister() to generate AML code for the
Generic Register Resource Descriptor. This function is
equivalent to the ASL macro Register().
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Remove the STATIC qualifier for the AmlUtility function
AmlNodeGetIntegerValue() and add the definition to the
header file so that it can be used by other AmlLib
sub-modules.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The node creation functions:
- AmlCreateRootNode()
- AmlCreateObjectNode()
- AmlCreateDataNode()
are now resetting the input pointer where the created node is stored.
Thus, it is not necessary to set some local variables to NULL or
check a node value before trying to delete it.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The following functions:
- AmlCreateRootNode()
- AmlCreateObjectNode()
- AmlCreateDataNode()
create a node and return it by populating a pointer. This pointer
should only be considered/used if the function returns successfully.
Otherwise, the value stored in this pointer should be ignored.
For their error handling, some other functions assume that this
pointer is reset to NULL if an error occurs during a node creation.
To make this assumption correct, explicitly clear this input pointer.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
ACPI 6.4, s6.4.2.9 "End Tag":
"This checksum is generated such that adding it to the sum of all the data
bytes will produce a zero sum."
"If the checksum field is zero, the resource data is treated as if the
checksum operation succeeded. Configuration proceeds normally."
To avoid re-computing checksums, if a new resource data elements is
added/removed/modified in a list of resource data elements, the AmlLib
resets the checksum to 0.
This patch also refactors the AmlAppendRdNode() function by getting the
last Resource Data node directly instead of iterating over all the
elements of the list of Resource Data node.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Lists of Resource Data elements end with an EndTag (most of the time).
This function finds the EndTag (if present) in a list of Resource Data
elements and sets the checksum.
ACPI 6.4, s6.4.2.9 "End Tag":
"This checksum is generated such that adding it to the sum of all the data
bytes will produce a zero sum."
"If the checksum field is zero, the resource data is treated as if the
checksum operation succeeded. Configuration proceeds normally."
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add AmlRdSetEndTagChecksum(), setting the CheckSum value contained in a
Resource Data element.
ACPI 6.4, s6.4.2.9 "End Tag":
"This checksum is generated such that adding it to the sum of all the
data bytes will produce a zero sum."
"If the checksum field is zero, the resource data is treated as if the
checksum operation succeeded. Configuration proceeds normally."
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
To fetch the Oem information from the ConfigurationManagerProtocol
and the AcpiTableInfo, and populate the SSDT ACPI header when
creating a RootNode via the AmlLib, create AddSsdtAcpiHeader().
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add parser support for the new "MinTransferSize" field of the System
Locality, Latency and Bandwidth structure, introduced by the ACPI
specification version 6.4.
Also update the HMAT parser to use the newer ACPI version 6.4
definitions.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Zhichao Gao <zhcihao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3666
Currently, CoreLocateHandleBuffer() follows three steps:
1) get the size of protocol database firstly
2) allocate the buffer based on the size
3) get the protocol database into the buffer
There is no lock protection for the whole three steps. If a new protocol
added in step 2) by other task, e.g. (event timer handle USB device
hotplug). The size of protocol database may be increased and cannot fit
into the previous buffer in step 3). The protocol database cannot be
returned successfully, EFI_BUFFER_TOO_SMALL error will be returned.
This patch adds the lock to protect the whole three steps.
It can make sure the correct protocol database be returned.
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: Hua Ma <hua.ma@intel.com>
Reviewed-by: Dandan Bi dandan.bi@intel.com
Reviewed-by: Liming Gao gaoliming@byosoft.com.cn
Buzilla: 3565 (https://bugzilla.tianocore.org/show_bug.cgi?id=3565)
As part of the updates to ACPI 6.4 the "SBSA Generic Watchdog" was
renamed to the "Arm Generic Watchdog". This patch implements that
change by updating the GTDT generator to use Acpi64.h and renames
any occurence of "SBSA Generic Watchdog" to "Arm Generic Watchdog".
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Microvm has no LPC bridge, so drop the PciSioSerialDxe driver.
Use SerialDxe instead, with ioport hardcoded to 0x3f8 aka com1 aka ttyS0.
With this tianocore boots to uefi shell prompt on the serial console.
Direct kernel boot can be used too.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3599
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
We just added the same functionality to the OvmfPkg. However, on x86, we
could use the notification mechanism around
gEfiDxeSmmReadyToLockProtocolGuid to indirectly invoke
ConfigureTpmPlatformHierarchy(). Since ARM does not have an SMM mode, we
have to use direct invocation of this function at the same place in
PlatformBootManagerBeforeConsole() as it is called on x86.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3510
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
According to the SMBIOS specification, the ExtendedBiosSize field should
be zero when the BIOS size is less than 16MB:
"Size (n) where 64K * (n+1) is the size of the
physical device containing the BIOS, in
bytes.
FFh - size is 16MB or greater, see Extended
BIOS ROM Size for actual size."
Fix the code in MiscBiosVendorFunction.c to only populate the
ExtendedBiosSize field if the BIOS size is greater than 16MB.
Fix the code to correctly populate the ExtendedBiosSize field with the
unit bits set to MB if the size is between 16MB and 16GB.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Nhi Pham <nhi@os.amperecomputing.com>
Rework all the functions to to have a generic prototype:
- First take take the resource data specific arguments.
E.g.: for a Register(): the AddressSpace, BitWidth, ...
- The penultimate parameter is a NameOpNode. The resource data
created is appended to the ResourceTemplate() contained in the
NameOpNode.
- The last parameter is a pointer holding the created resource data.
A least one of the two last parameter must be provided. One of them can
be omitted. This generic interface allows to either:
- Add the resource data to a NameOpNode. This is a common case for the
Ssdt tables generator.
- Get the created resource data and let the caller place it in an AML
tree.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Some functions in the AmlLib have 'Crs' in their name and can only
be applied to '_CRS' AML objects. To re-use them on AML objects that
have different names:
- Rename them and remove the '_CRS' name check.
- Create aliases having of the 'Crs' function prototypes. These
aliases are available when DISABLE_NEW_DEPRECATED_INTERFACES
is not defined. They will be deprecated in a near future.
The deprecated functions are:
- AmlNameOpCrsGetFirstRdNode()
- AmlNameOpCrsGetNextRdNode()
- AmlCodeGenCrsAddRdInterrupt()
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
To prepare edk2 upstream CI for incoming modifications:
1- Disable the Ecc check 9005:
"Only Doxygen commands '@bug', '@todo', [...], '@{', '@}'
are allowed to mark the code Unknown doxygen command [...]"
2- Disable the Ecc check 8003 for the following keyword:
"DISABLE_NEW_DEPRECATED_INTERFACES"
Indeed, this error has been corrected on the latest version of
BaseTools, but is still triggered when using the older python
packages containing the BaseTools.
3- Add word exceptions for the cspell tool.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The correct formatter to print a CHAR8 char in edk2 is '%a'.
Replace the '%s' formatters by '%a'.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The Platform information repository in the Configuration Manager
may be dynamically populated, for e.g. by a Hardware Information
Parser like FdtHwInfoParser. In such cases it is useful to trace
the CM objects that were populated by the parser.
Therefore, introduce helper functions that can parse and trace
the Configuration Manager Objects.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add a function converting a 7 characters string to its UINT32
EISAID. The algorithm used to create the EISAID is described
in the ACPI 6.4 specification, s19.3.4 "ASL Macros".
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Add HexFromAscii(), converting an hexadecimal ascii char
to an integer.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The Ecc tool forbids the usage of one char variable: Ecc error 8007:
"There should be no use of short (single character) variable names"
To follow this policy, rename this one letter parameter.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Update the inf file version and BASE_NAME of the library.
Remove unused sections.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The TableHelperLib contains helper functions. Some rely on
DynamicTablesPkg definitions (they use Configuration Manager objects).
Some others are more generic.
To allow using these generic functions without including
DynamicTablesPkg definitions, move them to a new AcpiHelperLib
library.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Remove asm code used for payload entry.
Use patchable PCD instead a fixed PCD PcdPayloadStackTop to avoid
potential conflict.
Based on the removal, use same HobLib regardless UNIVERSAL_PAYLOAD.
Use same PlatformHookLib regardless UNIVERSAL_PAYLOAD. The original
PlatformHookLib was removed and UniversalPayloadPlatformHookLib was
rename to new PlatformHookLib.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Activate the default console when user interaction is required for
the processing of TPM 2 physical presence interface opcodes.
Background:
TPM 2 physical presence interface (PPI) opcodes need to be handled before
the TPM 2 platform hierarchy is disabled. Due to this requirement we will
move the function call to handle the PPI opcodes into
PlatformBootManagerBeforeConsole() which runs before the initialization
of the consoles. However, since for interaction with the user we need
the console to be available, activate it now before displaying any message
to the user.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
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: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3653
The "target.txt" and "tools_def.txt" filenames are hard-coded
at some places when global definitions are available at:
BaseTools/Source/Python/Common/TargetTxtClassObject.py:
DefaultTargetTxtFile
and
BaseTools/Source/Python/Common/ToolDefClassObject.py:
DefaultToolsDefFile
Use these global definitions instead.
Also remove the unused gBuildConfiguration and gToolsDefinition
variables from build.py
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3653
Running the following command:
python3 build/build.py -a AARCH64 -t GCC5
-p ArmPlatformPkg/ArmPlatformPkg.dsc -b DEBUG libraries
triggers the following error:
make: *** Build/ArmPlatform/DEBUG_GCC5/AARCH64/MdePkg/Library/
BasePcdLibNull/BasePcdLibNull: Is a directory. Stop.
Indeed, MakefileName is set to en empty string. Setting MakefileName
resolves the error.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Linaro no longer do gcc releases - they're done by Arm now.
Update gcc_aarch64_linux_ext_dep.yaml to fetch the latest AARCH64 gcc
release (10.3-2021.07) from their site and fix LinuxGcc5ToolChain.py with the
new GCC_AARCH64_PREFIX.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Bob Feng <bob.c.feng@intel.com>
Linaro no longer do gcc releases - they're done by Arm now.
Update gcc_arm_linux_ext_dep.yaml to fetch the latest ARM gcc release
(10.3-2021.07) from their site and fix LinuxGcc5ToolChain.py with the
new GCC_ARM_PREFIX.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Bob Feng <bob.c.feng@intel.com>
V2: Use LittleEndianStructure by review comment.
From the universal scalable firmware payload requirement V0.75,
Payload must have Universal Payload Information Section ".upld_info"
So update the build tool to add this section.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Guo Dong <guo.dong@intel.com>
V2: Update BuildHobFromAcpi() to return a HOB pointer.
For universal UEFI payload, build a HOB from the ACPI table, so that
other modules could use this info from HOB at very early DXE phase.
This code are shared by universal payload and non universal payload.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Guo Dong <guo.dong@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3635
Currently, in order to test the supported attributes,
the PciTestSupportedAttribute() will set the command register
to 0x27 (EFI_PCI_COMMAND_IO_SPACE, EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER, EFI_PCI_COMMAND_VGA_PALETTE_SNOOP) firstly,
and then read back to check whether these attributes are
set successfully in the device.
This will cause the other enabled bits
(other than EFI_PCI_COMMAND_IO_SPACE,EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER,EFI_PCI_COMMAND_VGA_PALETTE_SNOOP)
be cleared for a short of time
This patch fixes this issue by keeping the origina
enabled bits when setting 0x27.
Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
Reviewed-by: Ray <ray.ni@intel.com>
Add support under a pcd feature for using the new interface to pass
initrd to the linux kernel instead of via device tree.
This feature is also enabled if ACPI tables are present, and will skip
locating and installation of device tree.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Currently if mAndroidBootImg->UpdateDtb is not supported on the platform
the device tree updates of the initrd are not made.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Update AndroidBootImgBoot to use a single return point
Make sure Kernel args are freed and Image is unloaded.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Remove duplicate libfdt.h include statement in AndroidBootImgLib
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
SEC checks in IsSevGuest if the PCD defined WorkAreaHeader size
matches the size of the WorkAreaHeader struct definition. Set a
default value for the PCD to avoid unnecessary DSC/FDF file
changes in all OVMF DSC/FDF files.
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3492
Currently SecCore.inf having the resetvector code under IA32. if the
user wants to use both SecCore and UefiCpuPkg ResetVector it's not
possible, since SecCore and ResetVector(VTF0.INF/ResetVector.inf)
are sharing the same GUID which is BFV. to overcome this issue we can
create the Duplicate version of the SecCore.inf as SecCoreNative.inf
which contains pure SecCore Native functionality without resetvector.
SecCoreNative.inf should have the Unique GUID so that it can be used
along with UefiCpuPkg ResetVector in there implementation.
Reviewed-by: 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>
Cc: Digant H Solanki <digant.h.solanki@intel.com>
Cc: Sangeetha V <sangeetha.v@intel.com>
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
According to SMBIOS 3.4, section 7.5.3.3 ARM64-class CPUs, if
SMCCC_ARCH_SOC_ID is supported, the first DWORD is the JEP-106 code and
the second DWORD is the SoC revision value. But in the current
implementation, they are set in reverse. This patch is to correct it.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Rebecca Cran <rebecca@nuviainc.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@nuviainc.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3473
X64 Reset Vector Code can access the memory range till 4GB using the
Linear-Address Translation to a 2-MByte Page, when user wants to use
more than 4G using 2M Page it will leads to use more number of Page
table entries. using the 1-GByte Page table user can use more than
4G Memory by reducing the page table entries using 1-GByte Page,
this patch attached can access memory range till 512GByte via Linear-
Address Translation to a 1-GByte Page.
Build Tool: if the nasm is not found it will throw Build errors like
FileNotFoundError: [WinError 2]The system cannot find the file specified
run the command wil try except block to get meaningful error message
Test Result: Tested in both Simulation environment and Hardware
both works fine without any issues.
Reviewed-by: 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>
Cc: Sangeetha V <sangeetha.v@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Sahil Dureja <sahil.dureja@intel.com>
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3621
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3631
Current CPU feature initialization design:
During normal boot, CpuFeaturesPei module (inside FSP) initializes the
CPU features. During S3 boot, CpuFeaturesPei module does nothing, and
CpuSmm driver (in SMRAM) initializes CPU features instead.
This code change prevents CpuSmm driver from re-initializing CPU
features during S3 resume if CpuFeaturesPei module has done the same
initialization.
In addition, EDK2 contains DxeIpl PEIM that calls S3RestoreConfig2 PPI
during S3 boot and this PPI eventually calls CpuSmm driver (in SMRAM) to
initialize the CPU features, so "EDK2 + FSP" does not have the CPU
feature initialization issue during S3 boot. But "coreboot" does not
contain DxeIpl PEIM and the issue appears, unless
"PcdCpuFeaturesInitOnS3Resume" is set to TRUE.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Import Tcg2PlatformPei from edk2-platforms without any modifications.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Introduce the new PCD
gEfiSecurityPkgTokenSpaceGuid.PcdRandomizePlatformHierarchy.
We need it for TpmPlatformHierarchyLib.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Import Tcg2PlatformDxe from edk2-platforms without any modifications.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
VerifyBlob() has been added recently to QemuKernelLoaderFsDxe, also
QemuKernelLoaderFsDxe has been added recently to OvmfXen but without an
implementation of VerifyBlob().
Fix this by adding the same runes that have been added to
OvmfPkgX64.dsc.
Fixes: 9f3eda177a ("OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Fix a typo of "memory" in a debug message in RamDiskProtocol.c.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
UefiPayloadEntry's AllocatePool() applies the "sizeof" operator to
HOB index rather than the HOB header structure. This yields 4 Bytes
compared to the 8 Bytes the structure header requires. Fix the call
to allocate the required space instead.
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: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin H?user <mhaeuser@posteo.de>
V1: Add quotes when using $(ARCH) in .dsc and .fdf file.
The quotes are added due to the way by which Core ci parse the .dsc file.
Add UINTN in Hob.c to fix cast from pointer to integer of different size error.
V2: Delete lines which reference ShellBinPkg.The pkg doesn't exist in edk2.
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: DunTan <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
There are several functions in OvmfPkg/Library using
QemuFwCfgS3Enabled() to detect the S3 support status. However, in
MdeModulePkg, PcdAcpiS3Enable is used to check S3 support. Since
InitializeXenPlatform() didn't set PcdAcpiS3Enable as
InitializePlatform() did, this made the inconsistency between
drivers/functions.
For example, S3SaveStateDxe checked PcdAcpiS3Enable and skipped
S3BootScript because the default value is FALSE. On the other hand,
PlatformBootManagerBeforeConsole() from OvmfPkg/Library called
QemuFwCfgS3Enabled() and found it returned TRUE, so it invoked
SaveS3BootScript(). However, S3SaveStateDxe skipped S3BootScript, so
SaveS3BootScript() asserted due to EFI_NOT_FOUND.
This issue mainly affects "HVM Direct Kernel Boot". When used,
"fw_cfg" is enabled in QEMU and QemuFwCfgS3Enabled() returns true in
that case.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3573
Signed-off-by: Gary Lin <gary.lin@hpe.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Jim Fehlig <jfehlig@suse.com>
This commit adds code which check BootDiscoveryPolicy variable and
calls Boot Policy Manager Protocol to connect device specified by
the variable. To enable that mechanism for platform
EfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy PCD must be
added to DSC file and BootDiscoveryPolicyUiLib should be added to
UiApp libraries.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This variable is needed to track the change to
BootDiscoveryPolicy variable. Boot options should
be refreshed only if BootDiscoveryPolicy has been
changed.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Now with everything in place for virtio 1.0 devices we can let
VirtioMmioInit() return SUCCESS.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Use QueueNumMax as QueueNum default for drivers which do not
explicitly call VIRTIO_DEVICE_PROTOCOL->SetQueueSize().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Virtio 1.0 allows a more flexible virtio ring layout, so we have to set
addresses for descriptors avail flags and use flags separately. We
continue to use a ring layout compatible with virtio 0.9.5 though, so no
other changes are needed to setup the virtio queues.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add #defines for the Version field. Read and store the version,
log the version found as info message.
Continue to return UNSUPPORTED for now, we need some more patches
to complete virtio 1.0 support first.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add defines for the config space offsets for virtio 1.0 mmio transport.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Currently, at ExitBootServices() time, the GICv3 driver signals
End-Of-Interrupt (EOI) on all interrupt lines that are supported by the
interrupt controller. This appears to have been carried over from the
GICv2 version, but has been turned into something that violates the GIC
spec, and may trigger SError exceptions on some implementations.
Marc puts it as follows:
The GIC interrupt state machine is pretty strict. An interrupt can
only be deactivated (with or without prior priority drop) if it has
been acknowledged first. In GIC speak, this means that only the
following sequences are valid:
With EOImode==0:
x = ICC_IAR{0,1}_EL1;
ICC_EOIR{0,1}_EL1 = x;
With EOImode==1:
x = ICC_IAR{0,1}_EL1;
ICC_EOIR{0,1}_EL1 = x;
ICC_DIR_EL1 = x;
Any write to ICC_EOIR{0,1}_EL1 that isn't the direct consequence of
the same value being read from ICC_IAR{0,1}_EL1, and with the correct
nesting, breaks the state machine and leads to unpredictable results
that affects *all* interrupts in the system (most likely, the priority
system is dead). See Figure 4-3 ("Interrupt handling state machine")
in Arm IHI 0069F for a description of the acceptable transitions.
Additionally, on implementations that have ICC_CTLR_EL1.SEIS==1, a
SError may be generated to signal the error. See the various
<quote>
IMPLEMENTATION_DEFINED "SError ....";
</quote>
that are all over the pseudocode contained in the same architecture
spec. Needless to say, this is pretty final for any SW that would do
silly things on such implementations (which do exist).
Given that in our implementation, every signalled interrupt is acked,
handled and EOId in sequence, there is no reason to EOI all interrupts
at ExitBootServices() time in the first place, so let's just drop this
code. This fixes an issue reported by Marc where an SError is triggered
by this code, bringing down the system.
Reported-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Map->Operation is used to select whether a DMA region that
is being bounced has the source buffer copied to it. Except
Map->Operation isn't yet set, so the behavior is somewhat
random. Instead use the passed in Operation parameter.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Adding two unit test case for UefiSortLib. One is a test on
sorting an array of UINT32 by using PerformQuickSort, another
is a test on comparing the same buffer by using StringCompare.
Add 'main' function name to ECC exception list to avoid ECC
error.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
This change allows to build StandaloneMmPkg components for 32bit Arm
StandaloneMm firmware.
This change mainly moves AArch64/ source files to Arm/ side directory
for several components: StandaloneMmCpu, StandaloneMmCoreEntryPoint
and StandaloneMmMemLib. The source file is built for both 32b and 64b
Arm targets.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Use intermediate (UINTN) cast when casting int from/to pointer. This
is needed as UINT64 values cast from/to 32bit pointer for 32bit
architectures.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Change GenFv for Arm architecture to generate a specific jump
instruction as image entry instruction, when the target entry label
is assembled with Thumb instruction set. This is possible since
SecCoreEntryAddress value fetched from the PE32 has its LSBit set when
the entry instruction executes in Thumb mode.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Changes in ArmPkg to prepare building StandaloneMm firmware for
32bit Arm architectures.
Adds ArmmmuStandaloneMmLib library to the list of the standard
components build for ArmPkg on when ARM architectures.
Changes path of source file AArch64/ArmMmuStandaloneMmLib.c
and compile it for both 32bit and 64bit architectures.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Defines ARM_SVC_ID_FFA_* and ARM_SVC_ID_SP_* identifiers for 32bit
function IDs as per SMCCC specification. Defines also generic ARM
SVC identifier macros to wrap 32bit or 64bit identifiers upon target
built architecture.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Public the header file, move RefishCrtLib.h from PrivateInclude/
to Include/.
RefishCrtLib.lib will be public later. (Moved out from PrivateLibrary/)
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Bugzilla: 3516 (https://bugzilla.tianocore.org/show_bug.cgi?id=3516)
This patch introduces a header file for the ACPI specification version
6.4. Currently it is based on the Acpi63.h header file however makes
six changes:
1. Replace all occurences of "6_3"/"6.3" with "6_4/6.4".
2. Remove the trailing underscore from the header guard in accordance
with the EDK2 coding standards, section 5.3.5.
3. Make Acpi64.h the latest ACPI definition included by Acpi.h.
4. Fix the BGRT Status field comment to match the ACPI 6.3A spec.
5. Fix several typos where definitions were named "PMMT" when it should
be "PMTT".
6. Fix a typo: "PPTT Platform Communication Channel" should be "PDTT
Platform Communication Channel".
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Change the default value of the below PCDs to diable some legacy feature.
gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDegradeResourceForOptionRom|FALSE
gUefiCpuPkgTokenSpaceGuid.PcdCpuNumberOfReservedVariableMtrrs|0
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>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Define some PCDs as DynamicEX PCD to be used as global variable.
Because PcdUartDefaultBaudRate is defined as DynamicEX, remove the code
to set it in platformlib. That code was actually redundant.
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>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Add the three PCDs as fixed at build PCD:
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister
The default value is defined as Macro, so it can be passed in at build
command.
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>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2855
The Tpm2GetCapabilitySupportedAndActivePcrs function prints a
count number that should reflect the *supported and currently
active* PCR banks, but the implementation in place displays
instead the count of the *supported PCR banks* retrieved
directly from the Tpm2GetCapabilityPcrs()
TPML_PCR_SELECTION output.
The counter should only take into account those PCRs banks
which are active.
Replaced usage of EFI_D_* for DEBUG_* definitions in debug
messages.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Qi Zhang <qi1.zhang@intel.com>
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
it can be used in a media device path to specify a Linux style initrd
that can be loaded by the OS using the LoadFile2 protocol.
Move these defines to MdePkg from OvmfPkg as these are relevant to
non-OVMF targets as well.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
This commit add option which allows reset content of Secure Boot
keys and databases to default variables.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
This commits adds modules and dependencies related
to initialization and usage of default Secure Boot
key variables to SecurityPkg.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
This application allows user to force key enrollment from
Secure Boot default variables.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
This driver initializes default Secure Boot keys and databases
based on keys embedded in flash.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This commits add file which can be included by platform Flash
Description File. It allows to specify certificate files, which
will be embedded into binary file. The content of these files
can be used to initialize Secure Boot default keys and databases.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This commit removes functions which were added
to SecureBootVariableLib. It also adds dependecy
on that library.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
moves generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for EmulatorPkg.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
moves generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for OvmfPkg.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
moves generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for ArmVirtPkg platform.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This commits add library, which consist functions to
enrolll Secure Boot keys and initialize Secure Boot
default variables. Some of the functions was moved
from SecureBootConfigImpl.c file.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This commits add library, which consist helper functions related
to creation/removal Secure Boot variables. Some of the functions
was moved from SecureBootConfigImpl.c file.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This library extends Boot Maintenance Menu and allows to select
Boot Discovery Policy. When choice is made BootDiscoveryPolicy
variable is set. Platform code can use this variable to decide
which class of device shall be connected.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
In Split tool, the copy file actions only need to
copy file content but not need to copy file metadata.
copy2() copies the file metadata that causes split
unit test failed under edk2-basetools CI environment.
So this patch changes the call of copy2() to copyfile().
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>
threading camelCase functions have preferred alternatives since
python2.6. python3.10 has started emitting DeprecationWarnings
for them
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch fixes two issues below:
1. SCT SetTime_Func failures.
- https://github.com/pftf/RPi4/issues/164
2. Using shell time and date commands to set time can't work.
The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER
error status.
The root cause is that LibSetTime() sets RtcEpochSeconds variable with
inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE,
the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the
variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a
preexisting variable is rewritten with different attributes,
SetVariable() shall not modify the variable and shall return
EFI_INVALID_PARAMETER.
Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute
to the first EfiSetVariable() call to make two calls consistent.
By the way, this patch also fix a minor issue with a debug message.
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
* Update GetMaintainer.py to support an optional GitHub ID at the
end of maintainer and reviewer lines.
* Remove contents after email address from standard output
* Fix minor issue in --lookup to convert file path separators
from '\' to '/' to be compatible with regular expression
file matching.
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: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The following changes were addressed,
1. Smbios specs 3.4.0 table-51 bit5&6, these fields moved
from specific MemoryArrayLocationCXLFlexbus10AddonCard
to generic MemoryArrayLocationCXLAddonCard
to address both CXL1.0 and 2.0 CXL revisions.
2. Smbios specs 3.4.0 table-79, The memory technology name changed
from MemoryTechnologyIntelPersistentMemory
to MemoryTechnologyIntelOptanePersistentMemory.
Signed-off-by: Thotala Gopi <gopi.thotala@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
cmd_load_symbols.py can only load symbols from FV. Add the possibility to
use UEFI console output to calculate dll load address and send
add-symbol-file commands directly to ArmDS debugger
dll load address can't be used directly from UEFI output, see comment in
DebugPeCoffExtraActionLib: "This may not work correctly if you generate
PE/COFF directly as then the Offset would not be required".
1) Use objdump -S module.dll | grep <_ModuleEntryPoint> to get offset
in dll (offset)
2) Use Entrypoint=<address> from UEFI console output (entrypoint)
3) dll load address is (entrypoint)-(offset)
Signed-off-by: Artem Kopotev <artem.kopotev@arm.com>
Tested-by: Pierre Gondois <Pierre.Gondois@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3483
This patch initializes the linked list RegisteredRamDisks in
RamDiskDxeEntryPoint before the registration of gEfiRamDiskProtocolGuid
with InstallMultipleProtocolInterfaces, allowing ramdisks to be created
via a callback installed with RegisterProtocolNotify as soon as the
protocol is registered.
Without this, calling RamDisk->Register() in the callback causes a crash:
ASSERT [RamDiskDxe] MdePkg/Library/BaseLib/LinkedList.c(75): List->ForwardLink != ((void *) 0)
Signed-off-by: Trammell Hudson <hudson@trmm.net>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The edk2 path and the workspace path are identical when running
Ecc on edk2. When running Ecc on another repository
(e.g.: edk2-platforms with edk2 as a submodule of edk2-platforms),
these directories are different. Indeed, in the latter configuration,
Ecc must run git commands on the tested repository, i.e. the workspace
directory, edk2-platforms.
Thus, rename edk2_path as workspace_path.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The BaseTools directory is currently being located as a
sub-directory of the WORKSPACE env var. This might not be
true in other environments. Cf EDKII Build Specification,
s4.1.3 "Build Process Restrictions":
There is no restriction on the location of the EDK_TOOLS_PATH,
it may be located within a directory identified as the
WORKSPACE directory, or in any other location that is
accessible on the development workstation.
Locate the BaseTools directory using EDK_TOOLS_PATH instead.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Currently, the ConvertFceToStructurePcd.py tool generate
StructurePcd dsc file with comments from UNI file including
non-ascii character. Following DSC spec, there should not have
non-ascii character in DSC file. This patch removes the non-ascii
character when adding the comment and changes the circle R to (R).
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* Enable Mergify queue feature to support auto rebase when
'push' label is set and gauarntee that all EDK II CI checks
are run before merging in changes with linear history.
* Use status checks configured in GitHub branch protections
* Allow non EDK II Maintainers to create a PR
Requires an EDK II Maintainer to accept the change and
request merge by adding 'push' label. Only EDK II Maintainers
have ability to set/clear labels.
* Do not automatically close PRs for personal builds.
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 D Kinney <michael.d.kinney@intel.com>
Acked-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3476
parseInfFile currently reading the EFI_BASE_ADDRESS from INF, once the
address found still it's continues to read the complete inf file which
is not required. once the EFI_BASE_ADDRESS read from the INF no need to
read the INF further.
MSFT compiler can generate the map file address 8 or 16 based on which
architecture the INF is compiler. currently it's support for IA32,
modified the patchfv to support for all.
modification of few typo errors in parseModMapFile, getCurr function
required
verification : Working Fine
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Cloud Hypervisor is KVM based VMM and is implemented in rust. Just like
other VMMs it need UEFI support to let ACPI work. That's why
Cloud Hypervisor is introduced here.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
There is no device like Fw-cfg in Qemu in Cloud Hypervisor, so a specific
Acpi handler is introduced here.
The handler implemented here is in a very simple way:
1. acquire the RSDP from the PCD variable in the top ".dsc";
2. get the XSDT address from RSDP structure;
3. get the ACPI tables following the XSDT structure and install them
one by one;
4. get DSDT address from FADT and install DSDT table.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The ArmVirtPkg\PlatformHasAcpiDtDxe implementation is not common
and is specific for Qemu. So add a Cloud Hypervisor specific
version that decides whether the firmware should expose an ACPI
based or a Device Tree based hardware description to an operating
system.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add OnigurumaUefiPort.h and OnigurumaUefiPort.c into ECC exception in
MdeModulePkg.ci.yaml in order to fix CI error.
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Memory buffer that is allocated by malloc() and realloc() will be
shifted by 8 bytes because Oniguruma keeps its memory signature. This 8
bytes shift is not handled while calling free() to release memory. Add
free() function to check Oniguruma signature before release memory
because memory buffer is not touched when using calloc().
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When enter SMM exception, there will be a stack switch only if the IST
field of the interrupt gate is set. When CET shadow stack feature is
enabled, if there is a stack switch between SMM exception and SMM, the
shadow stack token busy bit needs to be cleared when return from SMM
exception to SMM. In UEFI BIOS, only page fault exception does the stack
swith when SMM shack guard feature is enabled. The condition of clear
shadow stack token busy bit should be SMM stack guard enabled, CET shadows
stack feature enabled and page fault exception.
The shadow stack token should be initialized by UINT64.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3462
Signed-off-by: Sheng Wei <w.sheng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Qihua Zhuang <qihua.zhuang@intel.com>
Cc: Daquan Dong <daquan.dong@intel.com>
Cc: Justin Tong <justin.tong@intel.com>
Cc: Tom Xu <tom.xu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Per UEFI Spec 2.8 (UEFI_Spec_2_8_final.pdf, page 114)
5.2.3 Protective MBR
Table 20. Protective MBR Partition Record protecting the entire disk
The description for BootIndicator states the following:
> Set to 0x00 to indicate a non-bootable partition. If set to any
> value other than 0x00 the behavior of this flag on non-UEFI
> systems is undefined. Must be ignored by UEFI implementations.
Unfortunately, we have been incorrectly assuming that the
BootIndicator value must be 0x00, which leads to problems
when the 'pmbr_boot' flag is set on a disk containing a GPT
(such as with GNU parted). When the flag is set, the value
changes to 0x01, causing this check to fail and the system
is rendered unbootable despite it being valid from the
perspective of the UEFI spec.
To resolve this, we drop the check for the BootIndicator
so that we stop caring about the value set there, which
restores the capability to boot such disks.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3474
Cc: Chris Murphy <chrismurphy@fedoraproject.org>
Cc: David Duncan <davdunc@amazon.com>
Cc: Lazlo Ersek <lersek@redhat.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
Message-Id: <20210705093603.575707-1-ngompa@fedoraproject.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
It's neccessary to allocate a Graphics Stolen Memory area to enable
GPU-Passthrough for integrated Intel GPUs. Therefore, use a new
memory layout with a static Pci32Baseaddress.
Old layout:
[... , lowmemlimit] RAM
[lowmemlimit, 0xE000 0000] PCI Space
New layout:
[... , lowmemlimit] RAM
[lowmemlimit, gsmbase ] Memory hole (may be absent)
[gsmbase , 0xC000 0000] GSM (may be absent)
[0xC000 0000, 0xE000 0000] PCI Space
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Message-Id: <20210705110842.14088-2-c.koehne@beckhoff.com>
Introduce the NETWORK_ISCSI_MD5_ENABLE feature test macro for NetworkPkg.
When explicitly set to FALSE, remove MD5 from IScsiDxe's CHAP algorithm
list.
Set NETWORK_ISCSI_MD5_ENABLE to TRUE by default, for compatibility
reasons. Not just to minimize the disruption for platforms that currently
include IScsiDxe, but also because RFC 7143 mandates MD5 for CHAP, and
some vendors' iSCSI targets support MD5 only.
With MD5 enabled, IScsiDxe will suggest SHA256, and then fall back to MD5
if the target requests it. With MD5 disabled, IScsiDxe will suggest
SHA256, and break off the connection (and session) if the target doesn't
support SHA256.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210629163337.14120-7-lersek@redhat.com>
Introduce the "mChapHash" table, containing the hash algorithms supported
for CHAP. Hash algos listed at the beginning of the table are preferred by
the initiator.
In ISCSI_CHAP_STEP_ONE, send such a CHAP_A value that is the
comma-separated, ordered list of algorithm identifiers from "mChapHash".
Pre-format this value string at driver startup, in the new function
IScsiCHAPInitHashList().
(In IScsiCHAPInitHashList(), also enforce that every hash algo's digest
size fit into ISCSI_CHAP_MAX_DIGEST_SIZE, as the latter controls the
digest, outgoing challenge, and hex *allocations*.)
In ISCSI_CHAP_STEP_TWO, allow the target to select one of the offered hash
algorithms, and remember the selection for the later steps. For
ISCSI_CHAP_STEP_THREE, hash the challenge from the target with the
selected hash algo.
In ISCSI_CHAP_STEP_THREE, send the correctly sized digest to the target.
If the initiator wants mutual authentication, then generate a challenge
with as many bytes as the target's digest will have, in
ISCSI_CHAP_STEP_FOUR.
In ISCSI_CHAP_STEP_FOUR (i.e., when mutual authentication is required by
the initiator), verify the target's response (digest) with the selected
algorithm.
Clear the selected hash algorithm before every login (remember that in
IScsiDxe, every login is a leading login).
There is no peer-observable change from this patch, as it only reworks the
current MD5 support into the new internal representation.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210629163337.14120-5-lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
IScsiDxe uses the ISCSI_CHAP_RSP_LEN macro for expressing the size of the
digest (16) that it solely supports at this point (MD5).
ISCSI_CHAP_RSP_LEN is used for both (a) *allocating* digest-related
buffers (binary buffers and hex encodings alike), and (b) *processing*
binary digest buffers (comparing them, filling them, reading them).
In preparation for adding other hash algorithms, split purpose (a) from
purpose (b). For purpose (a) -- buffer allocation --, introduce
ISCSI_CHAP_MAX_DIGEST_SIZE. For purpose (b) -- processing --, rely on
MD5_DIGEST_SIZE from <BaseCryptLib.h>.
Distinguishing these purposes is justified because purpose (b) --
processing -- must depend on the hashing algorithm negotiated between
initiator and target, while for purpose (a) -- allocation --, using the
maximum supported digest size is suitable. For now, because only MD5 is
supported, introduce ISCSI_CHAP_MAX_DIGEST_SIZE *as* MD5_DIGEST_SIZE.
Note that the argument for using the digest size as the size of the
outgoing challenge (in case mutual authentication is desired by the
initiator) remains in place. Because of this, the above two purposes are
distinguished for the "ISCSI_CHAP_AUTH_DATA.OutChallenge" field as well.
This patch is functionally a no-op, just yet.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210629163337.14120-4-lersek@redhat.com>
RFC 7143 explains that a single iSCSI session may use multiple TCP
connections. The first connection established is called the leading
connection. The login performed on the leading connection is called the
leading login. Before the session is considered full-featured, the leading
login must succeed. Further (non-leading) connections can be associated
with the session later.
(It's unclear to me from RFC 7143 whether the non-leading connections
require individual (non-leading) logins as well, but that particular
question is irrelevant from the perspective of this patch; see below.)
The data model in IScsiDxe exhibits some confusion, regarding connection /
session association:
- On one hand, the "ISCSI_SESSION.Conns" field is a *set* (it has type
LIST_ENTRY), and accordingly, connections can be added to, and removed
from, a session, with the IScsiAttatchConnection() and
IScsiDetatchConnection() functions.
- On the other hand, ISCSI_MAX_CONNS_PER_SESSION has value 1, therefore no
session will ever use more than 1 connection at a time (refer to
instances of "Session->MaxConnections" in
"NetworkPkg/IScsiDxe/IScsiProto.c").
This one-to-many confusion between ISCSI_SESSION and ISCSI_CONNECTION is
very visible in the CHAP logic, where the progress of the authentication
is maintained *per connection*, in the "ISCSI_CONNECTION.AuthStep" field
(with values such as ISCSI_AUTH_INITIAL, ISCSI_CHAP_STEP_ONE, etc), but
the *data* for the authentication are maintained *per session*, in the
"AuthType" and "AuthData" fields of ISCSI_SESSION. Clearly, this makes no
sense if multiple connections are eligible for logging in.
Knowing that IScsiDxe uses only one connection per session (put
differently: knowing that any connection is a leading connection, and any
login is a leading login), there is no functionality bug. But the data
model is still broken: "AuthType", "AuthData", and "AuthStep" should be
maintained at the *same* level -- be it "session-level" or "(leading)
connection-level".
Fixing this data model bug is more than what I'm signing up for. However,
I do need to add one function, in preparation for multi-hash support:
whenever a new login is attempted (put differently: whenever the leading
login is re-attempted), which always happens with a fresh connection, the
session-level authentication data needs to be rewound to a sane initial
state.
Introduce the IScsiSessionResetAuthData() function. Call it from the
central -- session-level -- IScsiSessionLogin() function, just before the
latter calls the -- connection-level -- IScsiConnLogin() function.
Right now, do nothing in IScsiSessionResetAuthData(); so functionally
speaking, the patch is a no-op.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210629163337.14120-2-lersek@redhat.com>
For R_386_RELATIVE and R_X86_64_RELATIVE, today's logic assumes that
the content pointed by the Rela->r_offset is 0 but it's not always
TRUE. We observed that linker may set the content to Rela->r_addend.
The patch removes the assertion.
There is no functionality impact for this patch.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Per ELF spec, the DT_REL/DT_RELA tag in dynamic section stores the
virtual address of the relocation section.
But today's code logic treats it as the section offset and finds
the relocation section whose offset equals to DT_REL/DT_RELA.
The logic can work when the section offset equals to the section
virtual address. But when the ELF is generated from the link script
that reserves a sizeof(pe_header) in the file beginning, the section
offset doesn't equal to section virtual address. Such logic can
not find the relocation section.
The patch fixes this bug.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3396
This is a GUI interface that can be used by users who
would like to change configuration settings directly
from the interface without having to modify the source.
This tool depends on Python GUI tool kit Tkinter.
It runs on both Windows and Linux.
The user needs to load the YAML file along with DLT file
for a specific board into the ConfigEditor, change the desired
configuration values. Finally, generate a new configuration delta
file or a config binary blob for the newly changed values to take
effect. These will be the inputs to the merge tool or the stitch
tool so that new config changes can be merged and stitched into
the final configuration blob.
This tool also supports binary update directly and display FSP
information. It is also backward compatible for BSF file format.
Running Configuration Editor:
python ConfigEditor.py
Co-authored-by: Maurice Ma <maurice.ma@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Signed-off-by: Loo Tung Lun <tung.lun.loo@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3440
The definition of EFI_MM_RESERVED_MMRAM_REGION, according to PI Spec 1.5
is also referenced in EFI_PEI_MM_CONFIGURATION_PPI. Defining this
structure as is will enforce any potential usage of MM Configuration PPI
interface to include <Protocol/MmConfiguration.h>.
This change moves this structure definition to PiMultiPhase.h, which is
already included by Protocol/MmConfiguration.h through PiMmCis.h. It also
paves way for introducing Ppi/MmConfiguration.h with proper dependency.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When using the in-source BaseTools, edksetup.bat will exit with an
ERRORLEVEL of 1 because the line in toolsetup.bat
"%PYTHON_COMMAND% -c "import edk2basetools" >NUL 2>NUL"
fails.
Ensure ERRORLEVEL is set to 0 when edksetup.bat or toolsetup.bat is
successfully run.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Split is now a Python tool, so BaseTools\Bin\Win32\Split.exe no longer
exists. Remove the check for it from toolsetup.bat to prevent the
erroneous claim that the binary C tools are missing.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Edk2 bootloader will pass the pei pcd database, and UPL also contain a
PCD database.
Dxe PCD driver has the assumption that the two PCD database can be
catenated and the local token number should be successive。
This patch will manually fix up the UPL PCD database to meet that
assumption.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
From gUniversalPayloadExtraDataGuid Guid Hob, get the Dxe FV information,
and get the Dxe Core from the FV.
Also, make sure if there are muliple FV hob, the FV hob pointing to this FV
will be the first in the hob list.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
This patch create the UniversalPayload Entry based on the UefiPayload
Entry. It implements the logic to find a proper memory range to create the
new Hob and migrate the Hobs from Bootloader.
To make the change history clear, the logic to get the DxeCore will be in
the next patch.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
For payload entry, use PayloadEntryHobLib as HobLib and payload entry
should initialize hob base.
For DxeCore, use new added DxeHobLib as HobLib, and DxeCore will
initialize hob base.
For Dxe Driver, use new added DxeHobLib as HobLib, and use DxeHobListLib
to initialize hob base.
Adding a new library DxeHobLib + DxeHobListLib instead of using the
DxeHobLib.inf in MdePkg is because the constructor needed be separated
from DxeHobLib.
If not, when building UefiPayloadPkg, the dependency chain is as below:
DebugLib -> SerialPortLib -> PlatformHookLib -> HobLib -> DebugLib
Each library has a constructor, and this becomes a constructor circle.
To break the circle, separate the constructor from the HobLib as a new
DxeHobListLib, which won't depend on DebugLib.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Intel Platform utility Syscfg/sysfwupdt will trigger SMI
to enter BIOS interface. then BIOS invoke EncodePassword
in SMM mode to check password.
it's need sha384(in CryptSha512.c) in SMM mode.
the origin SmmCryptLib.lib size is 1389KB,
after changed, the size is 1391KB.
the origin RuntimeCryptLib.lib size is 911KB,
after changed,the size is 913KB.
in SmmCryptLib.inf and RuntimeCryptLib.inf,
change CryptSha512NULL.c to CryptSha512.c.
https://bugzilla.tianocore.org/show_bug.cgi?id=3423
Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Previous it would hang in CpuDxe if DXE drivers are dispatched above 4GB.
Now remove the work around since the fixed in CpuDxe are merged.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Currently several DXE crash due to invalid memory resource settings.
The PciHostBridgeDxe which expects the MMCONF and PCI Aperature
to be EfiMemoryMappedIO, but currently those regions are (partly)
mapped as EfiReservedMemoryType.
coreboot and slimbootloader provide an e820 compatible memory map,
which doesn't work well with EDK2 as the e820 spec is missing MMIO regions.
In e820 'reserved' could either mean "DRAM used by boot firmware" or "MMIO
in use and not detectable by OS".
Guess Top of lower usable DRAM (TOLUD) by walking the bootloader provided
memory ranges. Memory types of RAM, ACPI and ACPI NVS below 4 GiB are used
to increment TOLUD and reserved memory ranges touching TOLUD at the base
are also assumed to be reserved DRAM, which increment TOLUD.
Then mark everything reserved below TOLUD as EfiReservedMemoryType and
everything reserved above TOLUD as EfiMemoryMappedIO.
This fixes assertions seen in PciHostBridgeDxe.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
PCIe support has been added to the Kvmtool virtual machine
manager. Therefore, enable PCIe support for Kvmtool firmware.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
PCIe support has been added to Kvmtool Virtual Machine Manager.
The PCI host bridge utility lib is used to retrieve information
about the Root Bridges in a platform.
Therefore, add an instance of PciHostBridgeUtilityLib as this is
required to enable PCIe support for Kvmtool firmware.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Many of the cache definitions in ArmLibPrivate.h are being used outside
of ArmLib, in Universal/Smbios. Move them into ArmCache.h to make them
public, and remove the include of ArmLibPrivate.h from files in
Universal/Smbios.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Per discussion with MdeModulePkg package maintainer, add
Zhiguang as one of the reviewers for ACPI and SMBIOS modules.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445
Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.
This change switches the spellcheck for ArmPlatformPkg to AuditOnly to
avoid potentially numerous spell errors. The correction action is to be
revisited by package maintainers once the tool incompatibility is
resolved.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This is the fix of the regression issue at c6b872c6.
Based on ELF spec, readonly alloc section is .rodata section. It is used.
This fix is to add back original check logic for ELF section. Now,
the readonly alloc section and execute alloc section are regarded as .text.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Per universal payload spec, the payload is in ELF format.
The patch adds a payload loader that supports to load ELF image.
The location of extra data sections whose names start with "upld."
is stored in UNIVERSAL_PAYLOAD_EXTRA_DATA HOB.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
The payload is in ELF format per the universal payload spec.
UNIVERSAL_PAYLOAD_INFO_HEADER is stored in the ELF payload as a separate
section named ".upld_info".
Extra data needed by payload is stored in sections whose name starts
with ".upld.".
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
When passing PCD database from Edk2 boot loader to Universal Payload, the
local token number in boot loader PCD database can be different with that
in Payload PCD database.
Dynamic PCD directly use local token number, while DynamicEx will search
token number by Guid and ExTokenNumber, which are unique pair and can make
sure finding the correct token number in boot loader's PCD database.
Therefore, using DynamicEx instead of Dynamic.
Also, explicitly define some PCDs as DynamicEx, or their default type will
be Dynamic
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
If HOB contains APCI table information, entry point of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table
(starting with EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
is contained by a single gEfiAcpiTableGuid HOB.
If error happens when installing ACPI table, stop installing and removing
all the tables that are already added.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The default EfiSmbiosProtocol operates on an empty SMBIOS table.
The SMBIOS tables are provided by the bootloader on UefiPayloadPkg.
Scan for existing tables in SmbiosDxe and load them if they seem valid.
This fixes the settings menu not showing any hardware information, instead
only "0 MB RAM" was displayed.
Tests showed that the OS can still see the SMBIOS tables.
SmbiosDxe will get the SMBIOS from a guid Hob.
Also will keep the SmbiosHandle if it is available.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Currently, BDS driver will link a PlatformBootManagerLib, which contains
platform specific logic. This patch get the platform specific logic from
a protocol, so that platform logic for Boot manager can be in another
binary.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
IScsiDxe (that is, the initiator) receives two hex-encoded strings from
the iSCSI target:
- CHAP_C, where the target challenges the initiator,
- CHAP_R, where the target answers the challenge from the initiator (in
case the initiator wants mutual authentication).
Accordingly, we have two IScsiHexToBin() call sites:
- At the CHAP_C decoding site, check whether the decoding succeeds. The
decoded buffer ("AuthData->InChallenge") can accommodate 1024 bytes,
which is a permissible restriction on the target, per
<https://tools.ietf.org/html/rfc7143#section-12.1.3>. Shorter challenges
from the target are acceptable.
- At the CHAP_R decoding site, enforce that the decoding both succeed, and
provide exactly ISCSI_CHAP_RSP_LEN bytes. CHAP_R contains the digest
calculated by the target, therefore it must be of fixed size. We may
only call IScsiCHAPAuthTarget() if "TargetRsp" has been fully populated.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-11-lersek@redhat.com>
The IScsiHexToBin() function documents the EFI_BUFFER_TOO_SMALL return
condition, but never actually checks whether the decoded buffer fits into
the caller-provided room (i.e., the input value of "BinLength"), and
EFI_BUFFER_TOO_SMALL is never returned. The decoding of "HexStr" can
overflow "BinBuffer".
This is remotely exploitable, as shown in a subsequent patch, which adds
error checking to the IScsiHexToBin() call sites. This issue allows the
target to compromise the initiator.
Introduce EFI_BAD_BUFFER_SIZE, in addition to the existent
EFI_BUFFER_TOO_SMALL, for reporting a special case of the buffer overflow,
plus actually catch the buffer overflow.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-10-lersek@redhat.com>
The IScsiHexToBin() function has the following parser issues:
(1) If the *subject sequence* in "HexStr" is empty, the function returns
EFI_SUCCESS (with "BinLength" set to 0 on output). Such inputs should
be rejected.
(2) The function mis-handles a "HexStr" that ends with a stray nibble. For
example, if "HexStr" is "0xABC", the function decodes it to the bytes
{0xAB, 0x0C}, sets "BinLength" to 2 on output, and returns
EFI_SUCCESS. Such inputs should be rejected.
(3) If an invalid hex char is found in "HexStr", the function treats it as
end-of-hex-string, and returns EFI_SUCCESS. Such inputs should be
rejected.
All of the above cases are remotely triggerable, as shown in a subsequent
patch, which adds error checking to the IScsiHexToBin() call sites. While
the initiator is not immediately compromised, incorrectly parsing CHAP_R
from the target, in case of mutual authentication, is not great.
Extend the interface contract of IScsiHexToBin() with
EFI_INVALID_PARAMETER, for reporting issues (1) through (3), and implement
the new checks.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-9-lersek@redhat.com>
Considering IScsiBinToHex():
> if (((*HexLength) - 3) < BinLength * 2) {
> *HexLength = BinLength * 2 + 3;
> }
the following subexpressions are problematic:
(*HexLength) - 3
BinLength * 2
BinLength * 2 + 3
The first one may wrap under zero, the latter two may wrap over
MAX_UINT32.
Rewrite the calculation using SafeIntLib.
While at it, change the type of the "Index" variable from UINTN to UINT32.
The largest "Index"-based value that we calculate is
Index * 2 + 2 (with (Index == BinLength))
Because the patch makes
BinLength * 2 + 3
safe to calculate in UINT32, using UINT32 for
Index * 2 + 2 (with (Index == BinLength))
is safe too. Consistently using UINT32 improves readability.
This patch is best reviewed with "git show -W".
The integer overflows that this patch fixes are theoretical; a subsequent
patch in the series will audit the IScsiBinToHex() call sites, and show
that none of them can fail.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-6-lersek@redhat.com>
The "ISCSI_CHAP_AUTH_DATA.OutChallenge" field is declared as a UINT8 array
with ISCSI_CHAP_AUTH_MAX_LEN (1024) elements. However, when the challenge
is generated and formatted, only ISCSI_CHAP_RSP_LEN (16) octets are used
in the array.
Change the array size to ISCSI_CHAP_RSP_LEN, and remove the (now unused)
ISCSI_CHAP_AUTH_MAX_LEN macro.
Remove the "ISCSI_CHAP_AUTH_DATA.OutChallengeLength" field, which is
superfluous too.
Most importantly, explain in a new comment *why* tying the challenge size
to the digest size (ISCSI_CHAP_RSP_LEN) has always made sense. (See also
Linux kernel commit 19f5f88ed779, "scsi: target: iscsi: tie the challenge
length to the hash digest size", 2019-11-06.) For sure, the motivation
that the new comment now explains has always been there, and has always
been the same, for IScsiDxe; it's just that now we spell it out too.
No change in peer-visible behavior.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-4-lersek@redhat.com>
Commit c6b872c updates GenFw base code attribute to find .text section.
With GCC49 tool chain, aslc file is compiled into elf image.
But, its text section has no CODE attribute. So, it can't be detected
by new GenFw tool.For this type file. its text section is not required.
Its data section will be converted to acpi table.
This fix is to remove assert check when the generated image is ACPI data.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Tested-by: Leif Lindholm <leif@nuviainc.com>
The "OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf"
library instance is used in the following platform DSC files in edk2:
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
OvmfPkg/OvmfXen.dsc
The Xen customizations are very light-weight in this
PlatformBootManagerLib instance. Isolating them statically, for the sake
of the first three DSC files, would save negligible binary code size, and
would likely worsen code complexity (by way of introducing new internal
interfaces) or blow up source code size (by duplicating almost the entire
lib instance source code). So for now, keep this one bit of Xen dynamism
even on QEMU.
However, because it's only PlatformBootManagerLib now that uses
XenPlatformLib (for the above-stated enlightenment), restrict the
XenPlatformLib class resolution in the first three DSC files to the only
DXE driver that consumes PlatformBootManagerLib (and therefore
XenPlatformLib): BdsDxe. This will cause a build failure later if someone
attempts to call a XenPlatformLib API (that is, tries to re-introduce Xen
enlightenment) in a different module in these non-Xen DSC files.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-44-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Remove the SmbiosTablePublishEntry() function from "SmbiosPlatformDxe.c".
"SmbiosPlatformDxe.c" becomes hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, simplified for QEMU, to the existent
file "Qemu.c". The GetQemuSmbiosTables() function no longer needs to be
declared in "SmbiosPlatformDxe.h"; "SmbiosPlatformDxe.h" becomes
hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, renamed and simplified for Xen, to the
new, arch-independent file "Xen.c". (The existent Xen-specific C files are
arch-dependent.)
Update both INF files; remove the dependencies that are now superfluous in
each.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-43-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
"OvmfPkg/SmbiosPlatformDxe" is structured somewhat differently from the
drivers duplicated and trimmed thus far in this series. The final QEMU and
Xen versions will share a relatively significant amount of code, therefore
duplicating the whole driver is less useful, even temporarily. Instead,
duplicate the INF file, in preparation for customizing the entry point
function.
Because ArmVirtXen doesn't actually include OvmfPkg/SmbiosPlatformDxe [*],
there is only one platform that's supposed to consume the new driver:
OvmfXen. Switch OvmfXen to the new driver at once.
[*] See commit 164cf40383 ("OvmfPkg: SmbiosPlatformDxe: restrict current
Xen code to IA32/X64", 2015-07-26).
This patch is best viewed with "git show --find-copies-harder".
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-42-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
According to the function-top comment, SmbiosTablePublishEntry() is
supposed to return an error code if no SMBIOS data is found, from either
GetXenSmbiosTables() or GetQemuSmbiosTables(). Currently the function
returns EFI_SUCCESS in this case however (propagated from
gBS->LocateProtocol()). Make the return code match the documentation.
(This issue is not too important, but it gets in the way of splitting the
entry point function next.)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-38-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
- Sort all sections in the INF file.
- Remove unused packages (MdeModulePkg) and lib classes (BaseMemoryLib)
from the INF file.
- Restrict some lib classes (BaseLib, HobLib) and GUIDs (gEfiXenInfoGuid)
to IA32 and X64, in the INF file; only the IA32/X64 Xen implementation
requires these.
- Don't make "SmbiosPlatformDxe.h" #include everything just as a
convenience. Spell out directly needed #includes in every file (annotate
each with an example identifier consumed), drop unused #includes.
- Keep #includes sorted.
- Remove the leading underscore from the #include guard macro name in
"SmbiosPlatformDxe.h".
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-37-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
instance is used in the following platforms in edk2:
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfXen.dsc
Both platforms define "PcdPciDisableBusEnumeration" with Fixed-at-Build
access method, and TRUE value. Remove the PCD from the
PciHostBridgeLibScan instance, and everything else that is useful only
when the PCD is FALSE.
In practice, this removes the PciHostBridgeUtilityGetRootBridges()
function call, which is based on fw-cfg; see
"OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c".
(Note that the dependency on PciHostBridgeUtilityLib remains in place,
given that the PciHostBridgeLibScan instance continues using lower-level
functions from the library that do not depend on fw-cfg.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-34-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" instance is
used by the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All these platforms statically inherit PcdPciDisableBusEnumeration=FALSE
from "MdeModulePkg.dec". Remove the the PCD and everything that depends on
it from the PciHostBridgeLib instance. Namely, remove the logic that
determines the root bridge apertures by (a) scanning the entire bus,
device and function number space, and (b) parsing the BAR values that were
pre-set by the Bhyve or Xen machinery.
"XenSupport.c" used to be listed explicitly in "Maintainers.txt", remove
it from that spot too.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-33-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
At this point, the IncompatiblePciDeviceSupportDxe driver is included in
the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All those platforms inherit FALSE for "PcdPciDisableBusEnumeration" from
"MdeModulePkg.dec".
This makes the PcdGetBool() call in the entry point of the driver
superfluous; remove it. Clean up now unused dependencies in the INF file
as well.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-28-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Because "PcdPciDisableBusEnumeration" is always TRUE in the OvmfXen
platform, we can remove the delayed ACPI table installation from
XenAcpiPlatformDxe. A number of dependencies become useless this way;
remove them too.
(Note that, conversely, in the QemuFwCfgAcpiPlatformDxe driver, we
*cannot* assume that "PcdPciDisableBusEnumeration" is always FALSE,
regardless of Xen: in the ArmVirtQemu platform, the PCD may carry either
FALSE or TRUE, dependent on whether or not the QEMU "virt" machine
configuration includes a PCIe host controller, respectively.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-21-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" module is no longer
referenced in any platform DSC file; remove it.
That orphans the "AcpiPlatform.c", "Qemu.c" and "Xen.c" files in the
"OvmfPkg/AcpiPlatformDxe/" directory; remove them.
That in turn removes the only definitions of the InstallAcpiTable(),
QemuDetected(), QemuInstallAcpiTable(), InstallXenTables() functions in
the "OvmfPkg/AcpiPlatformDxe/" directory, so remove their declarations
from "AcpiPlatform.h".
Remove "OvmfPkg/AcpiPlatformDxe/Xen.c" from the "OvmfPkg: Xen-related
modules" section of "Maintainers.txt", as well.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-13-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
- #include only such public headers in "AcpiPlatform.h" that are required
by the function declarations and type definitions introduced in
"AcpiPlatform.h". Don't use "AcpiPlatform.h" as a convenience #include
file.
- In every file, list every necessary public #include individually, with
an example identifier that's actually consumed.
- Remove unnecessary lib classes, add unlisted lib classes.
- Remove unnecessary #include directives, add unlisted #include
directives.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-11-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Switch the historical OvmfPkg* platforms from the AcpiPlatformDxe driver
to the QemuFwCfgAcpiPlatformDxe driver. (The latter is used by the
ArmVirtQemu* platforms as well.)
The change effectively replaces the following call tree:
InstallAcpiTables [AcpiPlatform.c]
XenDetected [XenPlatformLib] *
InstallXenTables [Xen.c] *
GetXenAcpiRsdp [Xen.c] *
InstallQemuFwCfgTables [QemuFwCfgAcpi.c]
...
InstallOvmfFvTables [AcpiPlatform.c] *
QemuDetected [Qemu.c] *
LocateFvInstanceWithTables [AcpiPlatform.c] *
QemuInstallAcpiTable [Qemu.c] *
QemuInstallAcpiMadtTable [Qemu.c] *
CountBits16 [Qemu.c] *
QemuInstallAcpiSsdtTable [Qemu.c] *
GetSuspendStates [Qemu.c] *
PopulateFwData [Qemu.c] *
with the one below:
InstallAcpiTables [QemuFwCfgAcpiPlatform.c]
InstallQemuFwCfgTables [QemuFwCfgAcpi.c]
...
eliminating the sub-trees highlighted with "*".
There are two consequences:
(1) Xen compatibility is removed from the ACPI platform driver of the
historical OvmfPkg* platforms.
(2) The ACPI tables that are statically built into OVMF (via
"OvmfPkg/AcpiTables/AcpiTables.inf") are never installed. In
particular, OVMF's own runtime preparation of the MADT and SSDT is
eliminated.
Because of (2), remove the "OvmfPkg/AcpiTables/AcpiTables.inf" module as
well -- and then the ACPITABLE build rule too.
Note that (2) only removes effectively dead code; the QEMU ACPI
linker-loader has taken priority since QEMU 1.7.1 (2014). References:
- https://wiki.qemu.org/Planning/1.7
- https://wiki.qemu.org/Features/ACPITableGeneration
- edk2 commit 96bbdbc856 ("OvmfPkg: AcpiPlatformDxe: download ACPI
tables from QEMU", 2014-03-31)
- edk2 commit 387536e472 ("OvmfPkg: AcpiPlatformDxe: implement QEMU's
full ACPI table loader interface", 2014-09-22)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603
LLVM/CLANG8 formal release http://releases.llvm.org/download.html#8.0.0
It can be downloaded and installed in Windows/Linux/Mac OS.
CLANG8ELF tool chain is added to generate ELF image, and convert to PE/COFF.
On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed directory
For example:
set CLANG_HOST_BIN=n # use windows nmake
set CLANG8_BIN=C:\Program Files\LLVM\bin\
On Linux/Mac, set CLANG8_BIN=LLVM installed directory
This tool chain can be used to compile the firmware code. On windows OS,
Visual Studio is still required to compile BaseTools C tools and nmake.exe.
On Linux/Mac OS, gcc is used to compile BaseTools C tools. make is used
for makefile.
This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell.
This tool chain is verified in Windows/Linux and Mac OS.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
LLVM/CLANG doesn't support resource section generation when ELF image generated.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
CLANG8ELF tool chain generated ELF image with the different attributes
in section. Update GenFw to handle them.
1. .text section with writable attribute (support)
2. .reloc section has the symbol for *ABS* (skip)
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
LLVM LLD linker doesn't support common-page-size option. So, max-page-size
is used. To not impact GCC tool chain, new ClangBase.lds is added.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
This error was found while compiling VirtioMmioDeviceLib for X64
with the GCC5 toolchain, where EFIAPI makes a difference.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210602045935.762211-1-kraxel@redhat.com>
[lersek@redhat.com: prepend module name to subject, trim subject back to
allowed length]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
A NameSeg is made 4 chars.
Cf. ACPI 6.4 s20.2.2 "Name Objects Encoding":
NameSeg := <leadnamechar namechar namechar namechar>
Notice that NameSegs shorter than 4 characters are filled
with trailing underscores (‘_’s).
AML_NAME_SEG_SIZE is currently defined in:
- DynamicTablesPkg/Library/Common/AmlLib/AmlDefines.h
- MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
Since the value can be inferred from the ACPI specification
and to avoid multiple definitions, move it to
MdePkg/Include/IndustryStandard/
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3418
According to xhci spec, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status
stage. If Data Stage does not exist, the Transfer Type flag(TRT)
should be No Data Stage.
So if data length equals to 0, TRT is set to 0.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
GetWakeupTime should return full time information, including
the daylight/timezone. Make use of the existing non-volatile
variables for that purpose. Moreover add an error checking
of possibly invalid parameters.
This partially fixes FWTS and SCT Set/GetWakeupTime tests on
Marvell platforms.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3397
Current Ppi/MmControl.h file has structure definition of "struct
_PEI_MM_CONTROL_PPI". This name mismatches with its definition in PI
Specification v1.7 (Errata) as "struct _EFI_PEI_MM_CONTROL_PPI".
In addition, field types "PEI_MM_ACTIVATE" and "PEI_MM_DEACTIVATE" used
in "struct _PEI_MM_CONTROL_PPI" mismatches with the definition of
"EFI_PEI_MM_ACTIVATE" and "EFI_PEI_MM_DEACTIVATE" in the PI spec.
This change fixes these mismatches by using the PI spec defined names.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Fixes: 6f33f7a262
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3334
IntelFsp2WrapperPkg defines following PCDs:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdFlashMicrocodeOffset
But the PCD name caused confusion because UefiCpuPkg defines:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdCpuMicrocodePatchAddress in IntelFsp2WrapperPkg means the base
address of the FV that holds the microcode.
PcdCpuMicrocodePatchAddress in UefiCpuPkg means the address of the
microcode.
The relationship between the PCDs is:
IntelFsp2WrapperPkg.PcdCpuMicrocodePatchAddress
+ IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchAddress
IntelFsp2WrapperPkg.PcdCpuMicrocodePatchRegionSize
- IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchRegionSize
To avoid confusion and actually the PCDs in IntelFsp2WrapperPkg
are only used by a sample FSP-T wrapper, this patch removes
the 3 PCDs defined in IntelFsp2WrapperPkg.
The FSP-T wrapper is updated to directly use the ones in UefiCpuPkg.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3324
The SEV-ES stacks currently share a page with the reset code and data.
Separate the SEV-ES stacks from the reset vector code and data to avoid
possible stack overflows from overwriting the code and/or data.
When SEV-ES is enabled, invoke the GetWakeupBuffer() routine a second time
to allocate a new area, below the reset vector and data.
Both the PEI and DXE versions of GetWakeupBuffer() are changed so that
when PcdSevEsIsEnabled is true, they will track the previous reset buffer
allocation in order to ensure that the new buffer allocation is below the
previous allocation. When PcdSevEsIsEnabled is false, the original logic
is followed.
Fixes: 7b7508ad78
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <3cae2ac836884b131725866264e0a0e1897052de.1621024125.git.thomas.lendacky@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Checks if any formatted files from prior execution are present.
Existence of such files is an unexpected condition. This might result
from an error that occurred during a previous run or a premature exit from a debug scenario. In any case, the package should be clean before starting a new run.
f"{pre_existing_formatted_file_count} formatted files already exist. To prevent overwriting these files, please remove them before running this plugin.")
def_cleanup_temporary_directory(self)->None:
"""
Cleans up the temporary directory used for this execution instance.
This removes the directory and all files created during this instance.
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.
