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]
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183
Under SEV-ES, a write to the flash device is done using a direct VMGEXIT
to perform an MMIO write. The address provided to the MMIO write must be
the physical address of the MMIO write destitnation. During boot, OVMF
runs with an identity mapped pagetable structure so that VA == PA and the
VMGEXIT MMIO write destination is just the virtual address of the flash
area address being written.
However, when the UEFI SetVirtualAddressMap() API is invoked, an identity
mapped pagetable structure may not be in place and using the virtual
address for the flash area address is no longer valid. This results in
writes to the flash not being performed successfully. This can be seen
by attempting to change the boot order under Linux. The update will
appear to be performed, based on the output of the command. But rebooting
the guest will show that the new boot order has not been set.
To remedy this, save the value of the flash base physical address before
converting the address as part of SetVirtualAddressMap(). The physical
address can then be calculated by obtaining the offset of the MMIO target
virtual address relative to the flash base virtual address and adding that
to the original flash base physical address. The resulting value produces
a successful MMIO write during runtime services.
Fixes: 437eb3f7a8
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com>
[lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo
fix, in both the commit message and the code comment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
CpuS3DataDxe allocates the "RegisterTable" and "PreSmmInitRegisterTable"
arrays in ACPI_CPU_DATA just so every processor in the system can have its
own empty register table, matched by APIC ID. This has never been useful
in practice.
Given commit e992cc3f48 ("UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM
consumption in CpuS3.c", 2021-01-11), simply leave both
"AcpiCpuData->RegisterTable" and "AcpiCpuData->PreSmmInitRegisterTable"
initialized to the zero address. This simplifies the driver, and saves
both normal RAM (boot services data type memory) and -- in PiSmmCpuDxeSmm
-- SMRAM.
(This simplification backs out a good chunk of commit 1158fc8e2c
("OvmfPkg/CpuS3DataDxe: enable S3 resume after CPU hotplug", 2020-03-04).
But CpuS3DataDxe still differs between UefiCpuPkg and OvmfPkg, due to the
latter supporting CPU hotplug; thus, we can't remove OvmfPkg/CpuS3DataDxe
altogether.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3159
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210119155440.2262-5-lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Extend parameter list of PciHostBridgeUtilityGetRootBridges() with BusMin/
BusMax, so that the utility function could be compatible with ArmVirtPkg
who uses mutable bus range [BusMin, BusMax] insteand of [0, PCI_MAX_BUS].
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210119011302.10908-10-cenjiahui@huawei.com>
[lersek@redhat.com: fix logging of UINTN values BusMin, BusMax]
[lersek@redhat.com: keep zeroing of (*Count) centralized]
[lersek@redhat.com: fix typos in ExtraRootBridges comment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero,
then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list
length against the PCD.
This turns the time complexity of node-level APIs from constant to linear,
and that of full-list manipulations from linear to quadratic.
As an example, consider the EFI_SHELL_FILE_INFO list, which is a data
structure that's widely used in the UEFI shell. I randomly extracted 5000
files from "/usr/include" on my laptop, spanning 1095 subdirectories out
of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are
the wall-clock times:
PcdMaximumLinkedListLength PcdMaximumLinkedListLength
=1,000,000 =0
-------------------------- ---------------------------
FAT 4 min 31 s 18 s
virtio-fs 5 min 13 s 1 min 33 s
Checking list lengths against an arbitrary maximum (default: 1,000,000)
seems useless even in NOOPT and DEBUG builds, while the cost is
significant; so set the PCD to 0.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-10-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Some UEFI shell commands read and write files in chunks. The chunk size is
given by "PcdShellFileOperationSize", whose default in
"ShellPkg/ShellPkg.dec" is 4KB (0x1000).
The virtio-fs daemon of QEMU advertizes a 128KB maximum buffer size by
default, for the FUSE_WRITE operation.
By raising PcdShellFileOperationSize 32-fold, the number of FUSE write
requests shrinks proportionately, when writing large files. And when a
Virtio Filesystem is not used, a 128KB chunk size is still not
particularly wasteful.
Some ad-hoc measurements on my laptop, using OVMF:
- The time it takes to copy a ~270MB file from a Virtio Filesystem to the
same Virtio Filesystem improves from ~9 seconds to ~1 second.
- The time it takes to compare two identical ~270MB files on the same
Virtio Filesystem improves from ~11 seconds to ~3 seconds.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3125
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
We faced a problem with passing through a PCI device with 64GB BAR to UEFI
guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G
address which pushes physical address space to 37 bits. That is above
36-bit width that OVMF exposes currently to a guest without tweaking
PcdPciMmio64Size knob.
The reverse calculation using this knob was inhereted from QEMU-KVM
platform code where it serves the purpose of finding max accessible
physical address without necessary trusting emulated CPUID physbits value
(that could be different from host physbits). On Xen we expect to use
CPUID policy to level the data correctly to prevent situations with guest
physbits > host physbits e.g. across migrations.
The next aspect raising concern - resource consumption for DXE IPL page
tables and time required to map the whole address space in case of using
CPUID bits directly. That could be mitigated by enabling support for 1G
pages in DXE IPL configuration. 1G pages are available on most CPUs
produced in the last 10 years and those without don't have many phys bits.
Remove all the redundant code now (including PcdPciMmio64.. handling
that's not used on Xen anyway) and grab physbits directly from CPUID that
should be what baremetal UEFI systems do.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Julien Grall <julien@xen.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
[lersek@redhat.com: fix up authorship from groups.io-mangled From line]
[lersek@redhat.com: wrap commit message at 74 characters]
Commit 55ee36b0c4
("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib")
added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks
build of OvmfXen.dsc.
Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
Protect the GHCB backup pages used by an SEV-ES guest when S3 is
supported.
Regarding the lifecycle of the GHCB backup pages:
PcdOvmfSecGhcbBackupBase
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the GHCB backup pages are initialized when a
nested #VC is received during the SEC phase
[OvmfPkg/Library/VmgExitLib/SecVmgExitVcHandler.c].
(b) how it is protected from memory allocations during DXE
If S3 and SEV-ES are enabled, then InitializeRamRegions()
[OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
memory allocation HOB, in PEI.
If S3 is disabled, then these ranges are not protected. PEI switches to
the GHCB backup pages in permanent PEI memory and DXE will use these
PEI GHCB backup pages, so we don't have to preserve
PcdOvmfSecGhcbBackupBase.
(c) how it is protected from the OS
If S3 is enabled, then (b) reserves it from the OS too.
If S3 is disabled, then the range needs no protection.
(d) how it is accessed on the S3 resume path
It is rewritten same as in (a), which is fine because (b) reserved it.
(e) how it is accessed on the warm reset path
It is rewritten same as in (a).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <119102a3d14caa70d81aee334a2e0f3f925e1a60.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
In order to be able to issue messages or make interface calls that cause
another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support
for nested #VCs.
In order to support nested #VCs, GHCB backup pages are required. If a #VC
is received while currently processing a #VC, a backup of the current GHCB
content is made. This allows the #VC handler to continue processing the
new #VC. Upon completion of the new #VC, the GHCB is restored from the
backup page. The #VC recursion level is tracked in the per-vCPU variable
area.
Support is added to handle up to one nested #VC (or two #VCs total). If
a second nested #VC is encountered, an ASSERT will be issued and the vCPU
will enter CpuDeadLoop ().
For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory
layout, with two new fixed PCDs to provide the address and size of the
backup area.
For PEI/DXE, the GHCB backup pages are allocated as boot services pages
using the memory allocation library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
