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>
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3345
During PEI, the MMIO range for the TPM is marked as encrypted when running
as an SEV guest. While this isn't an issue for an SEV guest because of
the way the nested page fault is handled, it does result in an SEV-ES
guest terminating because of a mitigation check in the #VC handler to
prevent MMIO to an encrypted address. For an SEV-ES guest, this range
must be marked as unencrypted.
Create a new x86 PEIM for TPM support that will map the TPM MMIO range as
unencrypted when SEV-ES is active. The gOvmfTpmMmioAccessiblePpiGuid PPI
will be unconditionally installed before exiting. The PEIM will exit with
the EFI_ABORTED status so that the PEIM does not stay resident. This new
PEIM will depend on the installation of the permanent PEI RAM, by
PlatformPei, so that in case page table splitting is required during the
clearing of the encryption bit, the new page table(s) will be allocated
from permanent PEI RAM.
Update all OVMF Ia32 and X64 build packages to include this new PEIM.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <42794cec1f9d5bc24cbfb9dcdbe5e281ef259ef5.1619716333.git.thomas.lendacky@amd.com>
[lersek@redhat.com: refresh subject line]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules run before XenPlatformPei.
XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei
Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.
A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210412133003.146438-8-anthony.perard@citrix.com>
[lersek@redhat.com: cast Freq to UINT32 for PcdSet32S(), not for ASSERT()]
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).
The shared_info page is mapped at the highest physical address allowed
as it doesn't need to be in the RAM, thus there's a call to update the
page table.
The calculated frequency is only logged in this patch, it will be used
in a following patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210412133003.146438-7-anthony.perard@citrix.com>
Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.
While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G guest page table
into 4k pages and thus reducing performance of the guest when it
accesses its memory. Also mapping a page like the shared info page and
then unmapping it or mapping it somewhere else would leave a hole in
the RAM that the guest would propably not be able to use anymore.
So the patch introduces a new function which can be used to 1:1
mapping of guest physical memory above 4G during the PEI phase so we
can map the Xen shared pages outside of memory that can be used by
guest, and as high as possible.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210412133003.146438-6-anthony.perard@citrix.com>
The CommandLine and InitrdData may be set to NULL if the provided
size is too large. Because the zero page is mapped, this would not
cause an immediate crash but can lead to memory corruption instead.
This patch just adds validation and returns error if either allocation
has failed.
Signed-off-by: Martin Radev <martin.b.radev@gmail.com>
Message-Id: <YFPJsaGzVWQxoEU4@martin-ThinkPad-T440p>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
[lersek@redhat.com: drop unnecessary empty line from code; remove personal
(hence likely unstable) repo reference from commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add logic in EjectCpu() to do the actual the CPU ejection.
On the BSP, ejection happens by first selecting the CPU via
its QemuSelector and then sending the QEMU "eject" command.
QEMU in-turn signals the remote VCPU thread which context-switches
the CPU out of the SMI handler.
Meanwhile the CPU being ejected, waits around in its holding
area until it is context-switched out. Note that it is possible
that a slow CPU gets ejected before it reaches the wait loop.
However, this would never happen before it has executed the
"AllCpusInSync" loop in SmiRendezvous().
It can mean that an ejected CPU does not execute code after
that point but given that the CPU state will be destroyed by
QEMU, the missed cleanup is no great loss.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Aaron Young <aaron.young@oracle.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Message-Id: <20210312062656.2477515-10-ankur.a.arora@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: unneeded inner QemuSelector declaration in EjectCpu()
triggers VS warning #4456 (local variable shadowed); remove it]
