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>
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.
