ACPI tables may contain multiple fields which point to the same
destination table. For example, in some revisions, the FADT contains
both DSDT and X_DSDT fields, and they may both point to the DSDT.
Previously, if Qemu created QEMU_LOADER_ADD_POINTER linker commands for
such instances, the linking process would attempt to install the same
pointed-to table repeatedly. For tables of which there must only be one
instance, the call to AcpiProtocol->InstallAcpiTable() would fail during
the second linker command pointing to the same table, thus entirely
aborting the ACPI table linking process. In the case of tables of which
there may be multiple instances, the table would end up duplicated.
This change adds a memoisation data structure which tracks the table
pointers that have already been processed; even if the same pointer is
encountered multiple times, it is only processed once.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: DSDT<->XSDT typo, debug msg, and coding style fixups]
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=368
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
The memory free operation is empty function in PEI. The compiler
optimization will bring the build warning in openssl/crypto/mem.c:
warning C4718: 'CRYPTO_free': recursive call has no side
effects, deleting
This patch uses '/wd4718' to silence the build warning for PEI
module building.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
For current iSCSI protocol parsing, UINT16 truncation may be happened. Since
the Spec already have declaimed that 0 is TCP Protocol and 1+ is reserved, the
parsing can be refined as below:
if (StrCmp (ProtocolStr, L"TCP") == 0) {
ISCSIDevPath->NetworkProtocol = 0;
} else {
//
// Undefined and reserved.
//
ISCSIDevPath->NetworkProtocol = 1;
}
Cc: Warner Losh <imp@bsdimp.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Warner Losh <imp@bsdimp.com>
According UEFI Spec, set to zero StationIp means to let the underlying
IPv6 driver choose a source address. But currently, DNSv6 always return
EFI_NO_MAPPING. The issue is caused by below bugs in DnsDxe:
* Incorrect TPL(TPL_CALLBACK) usage during UDP configuration.
* Failed to create the timer used to get IPv6 mapping
* Doesn't check the Ip6Mode.IsStarted flag.
Cc: Zhang Lubo <lubo.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Zhang Lubo <lubo.zhang@intel.com>
The EFI_IMAGE_MACHINE_TYPE_SUPPORTED() macro is abused in the PeiCore
code to decide whether the system we are compiling for can deal with
executable code being copied elsewhere and executed from there.
As stated in the comment, this is fundamentally a property of the compiler
target, and so this should be made dependent on MDE_CPU_xxx preprocessor
defines, and not on whether or not the runtime target can deal with
PE/COFF images of a certain machine type.
On X86/IA32, this mostly boils down to the same thing, but not on other
architectures, so let's clean this up.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Pkcs7Sign, Rsa2048Sha256Sign and Rsa2048Sha256GenerateKeys doesn't work
on Linux. It needs to be changed with shell=True.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This patch update the wrapper implementation in TlsLib to align
with the latest OpenSSL-1.1.0xx API changes.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
OpenSSL-1.1.xx makes most data structures opaque.
This patch updates Public Key Cipher Wrapper implementations in
BaseCryptLib to use the accessor APIs for opaque object access.
The impacted interfaces includes RSA, DH, X509, PKCS7, etc.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gary Lin <glin@suse.com>
OpenSSL-1.1.xx makes most data structures opaque.
This patch updated HMAC Wrapper implementation with opaque
HMAC_CTX object.
The HmacXXGetContextSize() is marked as deprecated, and updated
to use the fixed HMAC_CTX size, which is just kept for compatibility.
New APIs (HmacXXNew(), HmacXXFree()) were added as the recommended
HMAC_CTX usage interfaces for HMAC-XXXX operations.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
openssl/include/openssl/lhash.h will bring C4090 build warning
issue, which is one known issue for OpenSSL under Visual Studio
toolchain.
Refer to https://github.com/openssl/openssl/issues/2214 for more
discussions against this.
Use /wd4090 to silence this build warning until OpenSSL fix this.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Cleaning-up CRT Library Wrapper for the third-party cryptography
library building. The changes includes
1. Rename OpenSslSupport.h to CrtLibSupport.h for future alternative
crypto provider support.
2. Remove all un-referenced CRT APIs and headers.
(NOTE: More cleans-up could be possible after OpenSSL integrate the
extra PR request: https://github.com/openssl/openssl/pull/2961)
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gary Lin <glin@suse.com>
In a couple of places, OpenSSL code uses the address of the
strcmp() function, and assigns it to another comparator function
pointer.
Unfortunately, this falls foul of the inconsistent function ABI
that we use in EDKII. We '#define strcmp AsciiStrCmp' but AsciiStrCmp
is an EFIAPI function with the Microsoft ABI. And we're assigning its
address to a non-EFIAPI function, which may well have a different ABI.
Fix this by providing an actual strcmp() function in the default ABI.
We already *had* a prototype for it in OpenSslSupport.h, which was
then superseded by the #define strcmp AsciiStrCmp.
Now, OpenSSL code *can* use &strcmp without problems.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gary Lin <glin@suse.com>
Add one new OpenSSL-HOWTO.txt to introduce how to clone / download
the latest OpenSSL release source for build.
ALso update buildinf.h to reflect the latest update time.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
OpenSSL-1.1.0xx configure mechanism was updated with new configdata.
This patch update process_file.sh script to new Perl-based script for
auto generation of file list and openssl config file (opensslconf.h).
This only needs to be done once by a developer when updating to a new
version of OpenSSL (or changing options, etc.). Normal users do not
need to do this, since the results are already stored in the EDK2 git
repository.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
This patch removes the EDKII-openssl-xxxx.patch, installation scripts,
and Patch-HOWTO.txt which were used for old OpenSSL-1.0.2xx enabling.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Updates .gitignore that masks the OpenSSL source:
1. Remove "Include/openssl" from .gitignore since we needn't duplicate
openssl headers now
2. Update "openssl-*" to "openssl*", since we use "openssl" instead of
"openssl-x.x.xx" as main source directory.
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Update OpensslLib INF files to support OpenSSL-1.1.0x source build.
The file list was generated from the latest OpenSSL-1.1.0e release.
Main changes to support OpensslLib build in this patch include:
1. Use "openssl" instead of "openssl-x.x.xx" as main source directory,
Also update include path in CryptoPkg.dec
2. Enable warnings in GCC builds;
3. Update Visual Studio build options to silence current possible build
warnings.
4. Move the default opensslconf.h to Include/openssl, and add one dummy
dso_conf.h for native UEFI build.
The OpensslLib module build was validated as
build -t VSXXXX -a XX -p CryptoPkg/CryptoPkg.dsc
-m CryptoPkg/Library/OpensslLib/OpensslLib.inf
(NOTE: The extra build options for ARM/RVCT/XCODE were kept, which expect
further optimizations from community)
Cc: Ting Ye <ting.ye@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gary Lin <glin@suse.com>
Update logic to install FvInfo PPI with its file system guid.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
As a follow up to the changes proposed by Laszlo to make ACPI and DT
mutually exclusive on ArmVirtQemu, this patch proposes a DT platform
DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
or installs the FV embedded DTB binary as a configuration table under
the appropriate GUID, depending on a preference setting recorded as
a UEFI variable, and configurable via a HII screen.
The DTB binary can be embedded in the firmware image by adding the
following to the platform .fdf file:
FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
SECTION RAW = SomePkg/path/to/foo.dtb
}
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The build flag and the FeaturePCD have no effect any longer, remove them.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
the guest. Showing both is never needed (it is actually detrimental to the
adoption of standards, such as SBSA / SBBR).
* Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
> Found FwCfg @ 0x9020008/0x9020000
> Found FwCfg DMA @ 0x9020010
> InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0
plus the usual messages. Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
> MEMATTR=0x13a675018
before it lists the ACPI tables one by one.
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches
the ACPI tables.
* With "-no-acpi", the firmware logs:
> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
> PlatformHasAcpiDtDxe | InstallProtocolInterface:
> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0
> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
> FdtClientDxe | 0x13FFBF000 to OS
> ...
> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
> DXE_CORE | loaded!!
> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
> DXE_CORE | not loaded!!
> ...
> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
> RamDiskDxe | Table Protocol, unable to publish RAM disks to
> RamDiskDxe | NFIT.
(BootGraphicsResourceTableDxe's ReadyToBoot callback --
InstallBootGraphicsResourceTable() -- handles the lack of
EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138caa018
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches the directory "/sys/firmware/devicetree/base", which contains a
large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern
matches no files.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
notification callback. Move the sysconfig table installation from the
entry point function to the callback.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In this patch, the ACPI protocol / driver chain is enabled dynamically,
when appropriate. This is being done in one larger patch, because
ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform
DSCs.
No change in behavior should be observable after this patch on any
ArmVirtPkg platform.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
according to ARM vs. AARCH64. At this point it differs from the QEMU
driver PlatformHasAcpiDtDxe in that this one always installs the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with a Device
Tree-based hardware description. This is not necessarily exclusive with
other types of hardware description (for example, an ACPI-based one).
A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.
In the DXE phase, the protocol is meant to be consumed by the platform
driver that
- owns the Device Tree description of the hardware, and
- is responsible for installing it as a system configuration table.
Said FDT-owner driver can wait for the protocol via DEPEX or protocol
notify.
Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere (for example in MdeModulePkg and SecurityPkg).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add the shorter-term library instance outlined in the previous patch to
EmbeddedPkg, so that we can imbue AcpiTableDxe with a protocol dependency
on EDKII_PLATFORM_HAS_ACPI_GUID.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with an ACPI-based
hardware description. This is not necessarily exclusive with other types
of hardware description (for example, a Device Tree-based one).
A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.
In the DXE phase, the protocol is meant to be depended-upon by
"MdeModulePkg/Universal/Acpi/AcpiTableDxe", indirectly:
* In the long term, interested platforms will establish this dependency by
hooking an (upcoming) NULL-class DepexLib instance into AcpiTableDxe in
their DSC files, pointing DepexLib's DEPEX through a FixedAtBuild PCD to
the GUID introduced here. (For the prerequisite BaseTools feature, refer
to <https://bugzilla.tianocore.org/show_bug.cgi?id=443>).
* In the short term, an interested platform may hook a private NULL-class
library instance (called e.g. "PlatformHasAcpiLib") into AcpiTableDxe.
Such a library instance would be a specialization of the above described
generic DepexLib, with the DEPEX open-coded on the GUID introduced here.
Either way, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled)
EFI_ACPI_SDT_PROTOCOL dependent on the platform's dynamic decision to
produce or not to produce a NULL protocol instance with this GUID.
In turn, other (platform and universal) DXE drivers that produce ACPI
tables will wait for EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL, via
DEPEX, protocol notify, or a simple gBS->LocateProtocol() in a "late
enough" callback (such as Ready To Boot).
Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere in MdeModulePkg and SecurityPkg. In addition, an effort is
made to avoid the phrase "AcpiPlatform", as that belongs to drivers /
libraries that produce platform specific ACPI content (as opposed to
deciding whether the entire firmware will have access to
EFI_ACPI_TABLE_PROTOCOL, or any similar facilities in the PEI phase).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 18f6d4df9e.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 78c41ff519.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
If CR0 PG bit is not set, it means paging is not enabled on BSP. Thus, Execute
Disable feature is not working actually. Thus, we cannot enable it on APs.
v2:
Correct the commit log.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Correct PCD declaration comments and add new PCDs in UNI file.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Using one specific name for global variable to save MP services protocol
pointer.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
In order to be able to produce meaningful diagnostic output when taking
synchronous exceptions that have been caused by corruption of the stack
pointer, prepare the EL0 stack pointer and switch to it when handling the
'Sync exception using SPx' exception class.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The current CPU_REGISTER_TABLE_ENTRY structure only defined UINT32 Index to
indicate MSR/MMIO address. It's ok for MSR because MSR address is UINT32 type
actually. But for MMIO address, UINT32 limits MMIO address exceeds 4GB.
This update on CPU_REGISTER_TABLE_ENTRY is to add additional UINT32 field
HighIndex to indicate the high 32bit MMIO address and original Index still
indicate the low 32bit MMIO address.
This update makes use of original padding space between ValidBitLength and
Value to add HighIndex.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The input parameter Index of PreSmmCpuRegisterTableWrite() and
CpuRegisterTableWrite() is defined as UINT32. Index is MSR/MMIO address that
will be saved in CPU register table. UINT32 blocks the MMIO address > 4GB.
This fix is to define Index to UINT64 instead of UINT32.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Phil Dennis-Jordan
Qin Long
Jiaxin Wu
Ard Biesheuvel
Yonghong Zhu
Liming Gao
Song, BinX
Ruiyu Ni
Laszlo Ersek
Dandan Bi
Jeff Fan