Invocations of EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() may
result in a crash when the value of PcdAcpiExposedTableVersions does
not include EFI_ACPI_TABLE_VERSION_1_0B.
The reason is that EFI_ACPI_TABLE_PROTOCOL::InstallAcpiTable() will
only populate the Rsdt1/Rsdt3 pointers when EFI_ACPI_TABLE_VERSION_1_0B
is set, whereas EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() will
invoke PublishTables with EFI_ACPI_TABLE_VERSION_1_0B alawys set,
resulting in a NULL pointer dereference of the Rsdt1/Rsdt3 pointers.
So take PcdAcpiExposedTableVersions into account for UninstallAcpiTable
as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
198a46d768 improved the DSDT and X_DSDT
fields mutual exclusion by checking FADT revision, but that breaks
some OS that has assumption to only consume X_DSDT field even the
DSDT address is < 4G.
To have better compatibility, this patch is to update the code to not
make FADT.{DSDT,X_DSDT} mutual exclusion, but always set both DSDT and
X_DSDT fields in the FADT when the DSDT address is < 4G.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Jeff Fan <jeff.fan@intel.com>
The ACPI specification, up to and including revision 5.1 Errata A, allows
the DSDT and X_DSDT fields to be both set in the FADT. (Obviously, this
only makes sense if the DSDT address is representable in 4 bytes.)
Starting with 5.1 Errata B, specifically for Mantis 1393
<https://mantis.uefi.org/mantis/view.php?id=1393>, the spec requires at
most one of DSDT and X_DSDT to be set to a nonzero value.
MdeModulePkg/AcpiTableDxe handles this mutual exclusion somewhat
inconsistently.
- If the caller of EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() installs the
tables in "DSDT, FADT" order, then we enforce the exclusion between the
DSDT and X_DSDT fields:
DSDT under 4GB FADT.DSDT FADT.X_DSDT [VARIANT B]
-------------- --------- -----------
yes set clear
no clear set
This behavior conforms to 5.1 Errata B. (And it's not required by
earlier versions of the spec.)
- If the caller passes in the tables in "FADT, DSDT" relative order, then
we do not enforce the exclusion:
DSDT under 4GB FADT.DSDT FADT.X_DSDT [VARIANT A]
-------------- --------- -----------
yes set set
no clear set
This satisfies 5.1 Errata A and earlier, but breaks 5.1 Errata B and
later.
Unify the handling of both relative orders. In particular, check the major
and minor version numbers in the FADT. If the FADT version is strictly
before 5.1, then implement [VARIANT A]. If the FADT version is equal to or
larger than 5.1, then implement [VARIANT B].
We make three observations:
- We can't check the FADT table version precisely against "5.1 Errata B";
erratum levels are not captured in the table. We err in the safe
direction, namely we enforce the exclusion for "5.1" and "5.1 Errata A".
- The same applies to "6.0" versus "6.0 Errata A". Because we cannot
distinguish these two, we consider "6.0" to be "equal to or larger than
5.1", and apply [VARIANT B], enforcing the exclusion.
- While a blanket [VARIANT B] would be simpler, there is a significant
benefit to [VARIANT A], under the spec versions that permit it:
compatibility with a wider range of OSPMs (typically, older ones).
For example, Igor reported about a "DELL R430 system with rev4 FADT
where DSDT and X_DSDT are pointing to the same address". Michael also
reported about several systems that exhibit the same.
Regression tested with the following KVM guests (QEMU built at
ata0def594286d, "Merge remote-tracking branch
'remotes/bonzini/tags/for-upstream' into staging", 2017-01-30):
- OVMF: boot and S3 suspend/resume
- Ia32, Q35, SMM
- Fedlet 20141209
- Ia32X64, Q35, SMM
- Fedora 22
- Windows 7
- Windows 8.1
- Windows 10
- Windows Server 2008 R2
- Windows Server 2012 R2
- Windows Server 2016 Tech Preview 4
- X64, I440FX, no SMM
- Fedora 24
- RHEL-6.7
- RHEL-7.2-ish
- ArmVirtQemu: boot test with virtio-gpu
- AARCH64
- Fedora 24
- RHELSA-7.3
- openSUSE Tumbleweed (4.8.4-based)
This change is connected to ASWG ticket
<https://mantis.uefi.org/mantis/view.php?id=1757>, which is now
closed/fixed.
Cc: Al Stone <ahs3@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Michael Tsirkin <mtsirkin@redhat.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This patch incurs no functional changes, it just removes some whitespace,
and also makes sure we always assign
AcpiTableInstance->Fadt3->Dsdt
first, and
AcpiTableInstance->Fadt3->XDsdt
second. The goal is to separate the syntactic changes from the functional
changes implemented by the next patch.
Cc: Al Stone <ahs3@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Michael Tsirkin <mtsirkin@redhat.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Some static scan tool may regard CurrentRsdtEntry to be potentially
referenced to NULL pointer if CurrentRsdtEntry == NULL is used in
the right above if condition judgment.
CopyMem (CurrentRsdtEntry, CurrentRsdtEntry + 1, (*NumberOfTableEntries - Index) * sizeof (UINT32));
It is introduced by commit f9bbb8d9c3.
To avoid it and have same style with
"((Xsdt == NULL) || CurrentTablePointer64 == (UINT64) (UINTN) Table->Table)",
use Rsdt instead of CurrentRsdtEntry to check against NULL.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Shumin Qiu <shumin.qiu@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Shumin Qiu <shumin.qiu@intel.com>
The assignment of CurrentRsdtEntry and its subsequent dereference are
subject to the same condition, but for some reason, VS2008 does not see
that and warns about the dereference possibly involving an uninitialized
pointer. Since the single statememt between the blocks is unrelated, we
can just move it and merge the two conditional blocks together.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
AARCH64 systems never require compatibility with legacy ACPI OSes, and
may not have any 32-bit addressable system RAM. To support ACPI on these
systems, we need to be able to relax the 4 GB allocation restriction.
So add a PCD PcdAcpiExposedTableVersions containing a bitmask describing
which ACPI versions are targeted, and wire it up it up to the memory
allocation calls in AcpiTableDxe/AcpiTableProtocol.c. I.e., if ACPI v1.0b
is not among the supported versions, the memory allocations are not limited
to 4 GB, and only table types that carry 64-bit addresses are emitted.
Note that this will inhibit the publishing of any tables that carry only
32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
UEFI spec has clear description below:
Configuration Table Groups
The GUID for a configuration table also defines a corresponding event group GUID with the same value.
If the data represented by a configuration table is changed,
InstallConfigurationTable() should be called.
When InstallConfigurationTable() is called, the corresponding event is signaled.
When this event is signaled,
any components that cache information from the configuration table can optionally update their cached state.
For example, EFI_ACPI_TABLE_GUID defines a configuration table for ACPI data.
When ACPI data is changed, InstallConfigurationTable() is called.
During the execution of InstallConfigurationTable(),
a corresponding event group with EFI_ACPI_TABLE_GUID is signaled,
allowing an application to invalidate any cached ACPI data.
But current implementation only InstallConfigurationTable() at first time ACPI data change.
if (((Version & EFI_ACPI_TABLE_VERSION_1_0B) != 0) &&
!AcpiTableInstance->TablesInstalled1) {
Status = gBS->InstallConfigurationTable (&gEfiAcpi10TableGuid, AcpiTableInstance->Rsdp1);
if (EFI_ERROR (Status)) {
return EFI_ABORTED;
}
AcpiTableInstance->TablesInstalled1 = TRUE;
}
if (((Version & ACPI_TABLE_VERSION_GTE_2_0) != 0) &&
!AcpiTableInstance->TablesInstalled3) {
Status = gBS->InstallConfigurationTable (&gEfiAcpiTableGuid, AcpiTableInstance->Rsdp3);
if (EFI_ERROR (Status)) {
return EFI_ABORTED;
}
AcpiTableInstance->TablesInstalled3= TRUE;
}
The AcpiTableInstance->TablesInstalled1 and AcpiTableInstance->TablesInstalled3 conditional judgment need to be removed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17885 6f19259b-4bc3-4df7-8a09-765794883524
The code in AcpiTableDxe handles the installation of FADT and FACS in both
possible orders. In the [FADT, FACS] installation order, the FACS is at
once linked into the FADT. In the [FACS, FADT] installation order, the
FACS is stashed temporarily, and it is linked into the FADT when the FADT
is installed later.
According to the ACPI specification, *at most one* of FADT.FirmwareCtrl
and FADT.XFirmwareCtrl may be nonzero. The code is aware of this
requirement, and it never sets both of them to nonzero values at once.
However, the code doesn't expect the following:
- The caller first installs the FACS, which is stashed. The address that
is saved happens to fall below 4GB.
- The caller then installs a FADT, with a zero FirmwareCtrl field, and a
nonzero (pre-populated) XFirmwareCtrl field.
In this case the code sets FADT.FirmwareCtrl to the less-than-4GB address
of the stashed FACS, and leaves the different nonzero value in
FADT.XFirmwareCtrl. This violates the ACPI specification.
Prevent this by always zeroing the field that we do *not* set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16659 6f19259b-4bc3-4df7-8a09-765794883524
ACPI4.0/5.0 have clear description:
FIRMWARE_CTRL: If the X_FIRMWARE_CTRL field contains a non zero value then this field must be zero.
X_FIRMWARE_CTRL: This field is used when the physical address of the FACS is above 4GB. If the FIRMWARE_CTRL field contains a non zero value then this field must be zero.
Update code in AcpiSupport/AcpiTable when it produces this field to set one only.
Update code in AcpiS3Save when it consumes this field, check 0 value.
Signed-off-by: jiewen.yao@intel.com
Reviewed-by: star.zeng@intel.com
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13981 6f19259b-4bc3-4df7-8a09-765794883524
FIRMWARE_CTRL: If the X_FIRMWARE_CTRL field contains a non zero value then this field must be zero.
X_FIRMWARE_CTRL: This field is used when the physical address of the FACS is above 4GB. If the FIRMWARE_CTRL field contains a non zero value then this field must be zero.
Update code in AcpiSupport/AcpiTable when it produces this field to set one only.
Update code in AcpiS3Save when it consumes this field, check 0 value.
Signed-off-by: jiewen.yao@intel.com
Reviewed-by: star.zeng@intel.com
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13980 6f19259b-4bc3-4df7-8a09-765794883524
* Universal/Acpi/AcpiTableDxe
Implementation of EFI_ACPI_TABLE_PROTOCOL
(MdePkg/Include/Protocol/AcpiTable.h)
* Universal/Acpi/AcpiPlatformDxe
Sample "ACPI Platform Driver" which populates the
system ACPI tables by reading them from an
FFS file and using EFI_ACPI_TABLE_PROTOCOL
to make them available to the system.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7917 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel
Star Zeng
Laszlo Ersek
jyao1
erictian
lgao4
rsun3
jchen20
hhtian
jljusten
eric_tian
vanjeff
xli24