RpmcLib.h and VariableKeyLib.h are header files required to access RPMC
device and Key generator from platform. They will be used to ensure the
integrity and confidentiality of NV variables.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Nishant C Mistry <nishant.c.mistry@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The UNIT_TEST_STATUS and FAILURE_TYPE have used 0 as status, so use 0 as
unknown is confused, remove it from array enumeration but keep it
location in the array.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Token pointer may be NULL, it should be checked before use it.
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: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The commit will introduce a static PCD to specify the periodic interval
for checking the AP status when MP services StartupAllAPs() and
StartupThisAP() are being executed in a non-blocking manner. Or in other
words, specifies the interval for callback function CheckApsStatus().
The purpose is to provide the platform owners with the ability to choose
the proper interval value to trigger CheckApsStatus() according to:
A) The number of processors in the system;
B) How MP services (StartupAllAPs & StartupThisAP) being used.
Setting the PCD to a small value means the AP status check callback will
be triggered more frequently, it can benefit the performance for the case
when the BSP uses WaitForEvent() or uses CheckEvent() in a loop to wait
for AP(s) to complete the task, especially when the task can be finished
considerably fast on AP(s).
An example is within function CpuFeaturesInitialize() under
UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c,
where BSP will perform the same task with APs and requires all the
processors to finish the task before BSP proceeds to its next task.
Setting the PCD to a big value, on the other hand, can reduce the impact
on BSP by the time being consumed in CheckApsStatus(), especially when the
number of processors is huge so that the time consumed in CheckApsStatus()
is not negligible.
The type of the PCD is UINT32, which means the maximum possible interval
value can be set to:
4,294,967,295 microseconds = 4,295 seconds = 71.58 minutes = 1.19 hours
which should be sufficient for usage.
For least impact, the default value of the new PCD will be the same with
the current interval value. It will be set to 100,000 microseconds, which
is 100 milliseconds.
Unitest done:
A) OS boot successfully;
B) Use debug message to confirm the 'TriggerTime' parameter for the
'SetTimer' service is the same before & after this patch.
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Brian J. Johnson <brian.johnson@hpe.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ard Biesheuvel [Sat, 7 Mar 2020 12:35:55 +0000 (13:35 +0100)]
ArmPkg/ArmMmuLib AARCH64: preserve attributes when replacing a table entry
Currently, depending on the size of the region being (re)mapped, the
page table manipulation code may replace a table entry with a block entry,
even if the existing table entry uses different mapping attributes to
describe different parts of the region it covers. This is undesirable, and
instead, we should avoid doing so unless we are disregarding the original
attributes anyway. And if we make such a replacement, we should free all
the page tables that have become orphaned in the process.
So let's implement this, by taking the table entry path through the code
for block sized regions if a table entry already exists, and the clear
mask is set (which means we are preserving attributes from the existing
mapping). And when we do replace a table entry with a block entry, free
all the pages that are no longer referenced.
Ard Biesheuvel [Sat, 7 Mar 2020 11:44:16 +0000 (12:44 +0100)]
ArmPkg/ArmMmuLib AARCH64: use helpers to determine table entry types
Given how the meaning of the attribute bits for page table entry types
is slightly awkward, and changes between levels, add some helpers to
abstract from this.
Ard Biesheuvel [Wed, 25 Mar 2020 14:54:09 +0000 (15:54 +0100)]
ArmPkg/ArmMmuLib AARCH64: limit recursion when freeing page tables
FreePageTablesRecursive () traverses the page table tree depth first
to free all pages that it finds, without taking into account the
level at which it is operating.
Since TT_TYPE_TABLE_ENTRY aliases TT_TYPE_BLOCK_ENTRY_LEVEL3, we cannot
distinguish table entries from block entries unless we take the level
into account, and so we may be dereferencing garbage if we happen to
try and free a hierarchy of page tables that has level 3 pages in it.
Let's fix this by passing the level into FreePageTablesRecursive (),
and limit the recursion to levels < 3.
Ard Biesheuvel [Wed, 25 Mar 2020 09:30:07 +0000 (10:30 +0100)]
ArmVirtPkg/PlatformPeiLib: add dummy assignment to work around older GCC
Older GCC (<= 4.9) fail to infer that Parent is never used unless it
has been assigned before, and may throw an error like
/work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:
In function ‘PlatformPeim’:
/work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:132:24:
error: ‘Parent’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
RangesProp = fdt_getprop (Base, Parent, "ranges", &RangesLen);
Set Parent to 0 at the start of the sequence to work around this.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2601 Fixes: 82662a3b5f56e974 ("ArmVirtPkg/PlatformPeiLib: discover the TPM base ...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ard Biesheuvel [Wed, 25 Mar 2020 09:07:43 +0000 (10:07 +0100)]
OvmfPkg/X86QemuLoadImageLib: add dummy assignment to work around GCC
GCC 4.8 or 4.9 may throw the following error when building OVMF:
Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c:
In function ‘QemuLoadKernelImage’:
Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c:416:30:
error: ‘CommandLine’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
UnicodeSPrintAsciiFormat (
cc1: all warnings being treated as errors
This is due to the fact that older GCCs fail to infer that CommandLine is
never actually used unless it has been assigned. So add a redundant NULL
assignment to help these older GCCs understand this.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2630 Fixes: 7c47d89003a6f ("OvmfPkg: implement QEMU loader library for X86 with ...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The following components are currently missing from the [Components]
section of ArmPlatformPkg.dsc:
* ArmPlatformPkg/Library/HdLcd/HdLcd.inf
* ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.inf
This commit includes the components in the package DSC build.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The following components are currently missing from the [Components]
section of ArmPkg.dsc:
* ArmPkg/Drivers/ArmCrashDumpDxe/ArmCrashDumpDxe.inf
* ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
* ArmPkg/Library/ArmMtlNullLib/ArmMtlNullLib.inf
* ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
This commit includes the components in the package DSC build.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
We meet a case that the DEC file declaring the PCD isn't
included in the INF.it cause build tools report Traceback error.
Remove raise statements that generate Tracebacks that were only
intended for development/debug. With the raise statements removed
proper error messages are shown.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch is to fix a build tool regression issue which was introduced
by commit 8ddec24dea74.
compiler output message includes localized string.
So build failed when code decode the stdout/stderr byte arrays.
The cause of the build failed is that Commit 8ddec24dea74
removed "errors='ignore'".
The build tool does not need to deal with localized string,
so we need to add "errors='ignore'".
this function is only invoked for structure PCDs.
Build failed if structurePcd is used in platform dsc file.
The patch is going to fixed this issue
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Leif Lindholm [Wed, 11 Mar 2020 15:10:18 +0000 (15:10 +0000)]
ArmVirtPkg: fix ASSERT in ArmVirtGicArchLib with virtualization=on
ArmVirtGicArchLib was originally implemented before virtualization
emulation was implemented in QEMU, and the GICv2 model implemented only
the physical copy of control registers.
Enabling virtualization emulation to QEMU adds also the virtual copy,
doubling the RegSize returned by FindCompatibleNodeReg () in
ArmVirtGicArchLibConstructor (). This triggered an ASSERT when running
QEMU with -M virt,virtualization=on. Address this by testing for both
possible valid values of RegSize.
Liming Gao [Thu, 12 Mar 2020 04:30:08 +0000 (12:30 +0800)]
OvmfPkg: Fix build failure with VS2015 tool chain
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2582
warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data
With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build.
Add a code comment that explains the nature of the NumberOfPages field
values. Including this kind of historical information was suggested by
Leif in <https://edk2.groups.io/g/devel/message/55797> (alternative link:
<http://mid.mail-archive.com/20200312104006.GB23627@bivouac.eciton.net>).
Right now, the most recent commit updating the page counts has been commit 991d95636264 ("[...] Update default memory type information to reduce EFI
Memory Map fragmentation.", 2010-07-16).
bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call
for action", recommend enabling the (adaptive) Memory Type Information
feature.
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS
figure#6 describes the Memory Type Information feature in detail; namely
as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE
Core, and BDS.
Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling
the Secure SMM Communication recommendation.
In the longer term, OVMF should install the WSMT ACPI table, and this
patch contributes to that.
Notes:
- the step in figure#6 where the UEFI variable is copied into the HOB is
covered by the DXE IPL PEIM, in the DxeLoadCore() function,
- "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC
default TRUE value, because both whitepapers indicate that BDS needs to
reset the system if the Memory Type Information changes.
Due to the previous patches in this series, the above PCDs are available
in the PEI phase, in the SMM_REQUIRE build.
FaultTolerantWritePei produces a GUID-ed HOB with
FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null
PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB.
VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes
the HOB (which is safe due to the DEPEX), and produces
EFI_PEI_READ_ONLY_VARIABLE2_PPI.
This enables read-only access to non-volatile UEFI variables in the PEI
phase, in the SMM_REQUIRE build.
For now, the DxeLoadCore() function in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the
"MemoryTypeInformation" variable, because OVMF's PlatformPei always
produces the MemoryTypeInformation HOB.
(Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build
the HOB, but that's in sync with DxeLoadCore() also not looking for either
the HOB or the UEFI variable.)
are always set to constant (invariable) values in the "-D SMM_REQUIRE"
build of OVMF. (That's because in the SMM build, actual pflash is a hard
requirement, and the RAM-based emulation is never available.)
Set said PCDs statically, at build. This will allow us to depend on their
values in the PEI phase.
When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report
file comparison).
When SMM_REQUIRE is TRUE, the report file shows the following changes:
- "PcdOvmfFlashNvStorageFtwSpareBase" and
"PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any
module directly,
- for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase"
and "PcdFlashNvStorageVariableBase64", the access method changes from
DYN to FIXED,
- for the latter PCDs, the zero (dynamic default) values are replaced with
the desired constants.
Laszlo Ersek [Tue, 10 Mar 2020 22:27:36 +0000 (23:27 +0100)]
OvmfPkg/QemuFlashFvbServices: factor out SetPcdFlashNvStorageBaseAddresses
Extract the dynamic setting of the
- PcdFlashNvStorageVariableBase64
- PcdFlashNvStorageFtwWorkingBase
- PcdFlashNvStorageFtwSpareBase
addresses to a helper function.
For now, the helper function is identical (duplicated) between the SMM
flash driver and the runtime DXE flash driver. In subsequent patches, this
will change.
Laszlo Ersek [Tue, 10 Mar 2020 22:27:35 +0000 (23:27 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: drop unused PCDs
The only two OvmfPkg references to "PcdFlashNvStorageVariableBase" are the
spurious ones in the runtime DXE driver and the SMM driver INF files of
the QEMU flash driver. Remove these references.
The flash driver does not access "PcdOvmfFlashNvStorageEventLogBase"
either, so remove that from the INF files too.
From the function description of GetIfrBinaryData(), FormSetGuid can be
NULL. However, FormSetGuid is passed to IsZeroGuid(). This causes exception
when FormSetGuid is NULL.
Signed-off-by: Nickle Wang <nickle.wang@hpe.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Ovmf build failed on Windows with VS2017 tool chain.
The error message like:
OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitr
dDynamicShellCommand.c(199): error C2220: warning treated as error -
no 'object' file generated
OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitrdDynamicShellCommand.c(199):
warning C4244: '=': conversion from 'UINT64' to 'UINTN',
possible loss of data
This patch is to cast UINT64 type to UINTN type
when doing the variable assignment.
PcdValueInit shares the same Edk2\BaseTools\Source\C\PcdValueCommon.c.
To avoid the conflict, it should copy this file to its output directory,
If so, PcdValueCommon.c file will be private for PcdValueInit
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Laszlo Ersek [Tue, 10 Mar 2020 17:50:25 +0000 (18:50 +0100)]
OvmfPkg: raise DXEFV size to 12 MB
Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've
outgrown DXEFV again. Increase the DXEFV size to 12MB now.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2585 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310175025.18849-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ard Biesheuvel [Sat, 7 Mar 2020 09:10:08 +0000 (10:10 +0100)]
ArmPkg/ArmMmuLib AARCH64: cosmetic fixups
Some cosmetic fixups to the AArch64 MMU code:
- reflow overly long lines unless it hurts legibility
- add/remove whitespace according to the [de facto] coding style
- use camel case for goto labels
Ard Biesheuvel [Sat, 7 Mar 2020 09:10:07 +0000 (10:10 +0100)]
ArmPkg/ArmMmuLib AARCH64: drop pointless page table memory type check
This is the AARCH64 counterpart of commit 1f3b1eb3082206e4, to remove
a pointless check against the memory type of the allocations that the
page tables happened to land in. On ArmV8, we use writeback cacheable
exclusively for all memory.
Ard Biesheuvel [Sat, 7 Mar 2020 08:38:49 +0000 (09:38 +0100)]
ArmPkg/ArmMmuLib AARCH64: invalidate page tables before populating them
As it turns out, ARMv8 also permits accesses made with the MMU and
caches off to hit in the caches, so to ensure that any modifications
we make before enabling the MMU are visible afterwards as well, we
should invalidate page tables right after allocation like we do now on
ARM, if the MMU is still disabled at that point.
Ard Biesheuvel [Sat, 7 Mar 2020 08:38:48 +0000 (09:38 +0100)]
ArmPkg/ArmMmuLib AARCH64: rewrite page table code
Replace the slightly overcomplicated page table management code with
a simplified, recursive implementation that should be far easier to
reason about.
Note that, as a side effect, this extends the per-entry cache invalidation
that we do on page table entries to block and page entries, whereas the
previous change inadvertently only affected the creation of table entries.
Laszlo Ersek [Fri, 6 Mar 2020 23:04:42 +0000 (00:04 +0100)]
OvmfPkg/X86QemuLoadImageLib: fix "unused variable" error in X64 DXE builds
When the MDE_CPU_IA32 macro is not defined, there is no access to the
"KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8.
Move the local variable to the inner scope, where declaration and usage
are inseparable.
(Note that such inner-scope declarations are frowned upon in the wider
edk2 codebase, but we use them liberally in ArmVirtPkg and OvmfPkg anyway,
because they help us reason about variable lifetime and visibility.)
Ard Biesheuvel [Fri, 6 Mar 2020 07:34:24 +0000 (08:34 +0100)]
OvmfPkg/QemuKernelLoaderFsDxe: drop tentative const object definition
Bob reports that VS2017 chokes on a tentative definition of the const
object 'mEfiFileProtocolTemplate', with the following error:
OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130):
error C2220: warning treated as error - no 'object' file generated
OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130):
warning C4132: 'mEfiFileProtocolTemplate': const object should be initialized
Let's turn the only function that relies on this tentative definition
into a forward declaration itself, and move its definition after the
external definition of the object. That allows us to drop the tentative
definition of the const object, and hopefully make VS2017 happy.
Ard Biesheuvel [Thu, 5 Mar 2020 21:21:15 +0000 (22:21 +0100)]
OvmfPkg/OvmfXen: fix build by providing QemuLoadImageLib resolution
Commit 859b55443a4253ba ("OvmfPkg/PlatformBootManagerLib: switch to
QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on
QemuLoadImageLib in the PlatformBootManagerLib implementation that is
shared between all OVMF builds, without taking into account that even
the Xen targeted builds incorporate this code, which is only used to
load kernels passed via the QEMU command line.
Since this is dead code on Xen, we can satisfy the dependency using
the generic version of QemuLoadImageLib, which does not rely on
LoadLinuxLib, which we can therefore drop from OvmfXen.dsc.
Ard Biesheuvel [Thu, 5 Mar 2020 12:49:32 +0000 (13:49 +0100)]
ArmPkg/ArmMmuLib ARM: drop memory type check for page tables
We already expect normal memory to be mapped writeback cacheable if
EDK2 itself is to make use of it, so doing an early sanity check on
the memory type of the allocation that the page tables happened to
land in isn't very useful. So let's drop it.
Ard Biesheuvel [Thu, 5 Mar 2020 12:36:14 +0000 (13:36 +0100)]
ArmPkg/ArmMmuLib ARM: simplify assignment of TTBR0 system register
The expression passed into ArmSetTTBR0 () in ArmConfigureMmu() is
sub-optimal at several levels:
- TranslationTable is already aligned, and if it wasn't, doing it
here wouldn't help
- TTBRAttributes is guaranteed not to have any bits set outside of
the 0x7f mask, so the mask operation is pointless as well,
- an additional (UINTN) cast for good measure is also not needed.
Ard Biesheuvel [Wed, 26 Feb 2020 13:07:32 +0000 (14:07 +0100)]
ArmPkg/ArmLib: ASSERT on set/way cache ops being used with MMU on
On ARMv7 and up, doing cache maintenance by set/way is only
permitted in the context of on/offlining a core, and any other
uses should be avoided. Add ASSERT()s in the right place to
ensure that any uses with the MMU enabled are caught in DEBUG
builds.
Ard Biesheuvel [Wed, 26 Feb 2020 12:49:03 +0000 (13:49 +0100)]
ArmPkg/ArmLib: clean up library includes
Suspiciously, ArmLib's INF does not contain a [LibraryClasses]
section at all, but it turns out that all the library includes
it contains (except for ArmLib.h itself) are actually bogus so
let's just drop all of them. While at it, replace <Uefi.h> with
the more accurate <Base.h> for a BASE type module, and put the
includes in a consistent order.
Ard Biesheuvel [Wed, 26 Feb 2020 09:07:37 +0000 (10:07 +0100)]
ArmPkg/ArmLib: move set/way helper functions into private header
The clean/invalidate helper functions that operate on a single cache
line identified by set, way and level in a special, architected format
are only used by the implementations of the clean/invalidate routines
that operate on the entire cache hierarchy, as exposed by ArmLib.
The latter routines will be deprecated soon, so move the helpers out
of ArmLib.h and into a private header so they are safe from abuse.
In the AARCH64 version of ArmMmuLib, we are currently relying on
set/way invalidation to ensure that the caches are in a consistent
state with respect to main memory once we turn the MMU on. Even if
set/way operations were the appropriate method to achieve this, doing
an invalidate-all first and then populating the page table entries
creates a window where page table entries could be loaded speculatively
into the caches before we modify them, and shadow the new values that
we write there.
So let's get rid of the blanket clean/invalidate operations, and
instead, update ArmUpdateTranslationTableEntry () to invalidate each
page table entry *after* it is written if the MMU is still disabled
at this point.
On ARMv8, it is guaranteed that memory accesses done by the page table
walker are cache coherent, and so we can ignore the case where the
MMU is on.
Since the MMU and D-cache are already off when we reach this point, we
can drop the MMU and D-cache disables as well. Maintenance of the I-cache
is unnecessary, since we are not modifying any code, and the installed
mapping is guaranteed to be 1:1. This means we can also leave it enabled
while the page table population code is running.
In the ARM version of ArmMmuLib, we are currently relying on set/way
invalidation to ensure that the caches are in a consistent state with
respect to main memory once we turn the MMU on. Even if set/way
operations were the appropriate method to achieve this, doing an
invalidate-all first and then populating the page table entries creates
a window where page table entries could be loaded speculatively into
the caches before we modify them, and shadow the new values that we
write there.
So let's get rid of the blanket clean/invalidate operations, and instead,
invalidate each page table right after allocating it, and each section
entry after it is updated (to address all the little corner cases that the
ARMv7 spec permits), and invalidate sets of level 2 entries in blocks,
using the generic invalidation routine from CacheMaintenanceLib
On ARMv7, cache maintenance may be required also when the MMU is
enabled, in case the page table walker is not cache coherent. However,
the code being updated here is guaranteed to run only when the MMU is
still off, and so we can disregard the case when the MMU and caches
are on.
Since the MMU and D-cache are already off when we reach this point, we
can drop the MMU and D-cache disables as well. Maintenance of the I-cache
is unnecessary, since we are not modifying any code, and the installed
mapping is guaranteed to be 1:1. This means we can also leave it enabled
while the page table population code is running.
Ard Biesheuvel [Thu, 5 Mar 2020 09:42:15 +0000 (10:42 +0100)]
ArmPkg/ArmMmuLib ARM: use AllocateAlignedPages() for alignment
Instead of overallocating memory and align the resulting base address
manually, use the AllocateAlignedPages () helper, which achieves the
same, and might even manage that without leaking a chunk of memory of
the same size as the allocation itself.
While at it, fix up a variable declaration in the same hunk, and drop
a comment whose contents add nothing to the following line of code.
Ard Biesheuvel [Wed, 26 Feb 2020 09:36:49 +0000 (10:36 +0100)]
ArmPkg/ArmMmuLib ARM: split ArmMmuLibCore.c into core and update code
Unlike the AArch64 implementation of ArmMmuLib, which combines the
initial page table population code with the code that runs at later
stages to manage permission attributes in the page tables, ARM uses
two completely separate sets of routines for this.
Since ArmMmuLib is a static library, we can prevent duplication of
this code between different users, which usually only need one or
the other. (Note that LTO should also achieve the same.)
This also makes it easier to reason about modifying the cache
maintenance handling, and replace the set/way ops with by-VA
ops, since the code that performs the set/way ops only executes
when the MMU is still off.
Ard Biesheuvel [Tue, 25 Feb 2020 18:28:34 +0000 (19:28 +0100)]
ArmPlatformPkg/PrePi: replace set/way cache ops with by-VA ones
Cache maintenance operations by set/way are only intended to be used
in the context of on/offlining a core, while it has been taken out of
the coherency domain. Any use intended to ensure that the contents of
the cache have made it to main memory is unreliable, since cacheline
migration and non-architected system caches may cause these contents
to linger elsewhere, without being visible in main memory once the
MMU and caches are disabled.
In KVM on Linux, there are horrid hacks in place to ensure that such
set/way operations are trapped, and replaced with a single by-VA
clean/invalidate of the entire guest VA space once the MMU state
changes, which can be costly, and is unnecessary if we manage the
caches a bit more carefully, and perform maintenance by virtual
address only.
So let's get rid of the call to ArmInvalidateDataCache () in the
PrePeiCore startup code, and instead, invalidate the UEFI memory
region by virtual address, which is the only memory region we will
be touching with the caches and MMU both disabled and enabled.
(This will lead to data corruption if data written with the MMU off
is shadowed by clean, stale cachelines that stick around when the
MMU is enabled again.)
Ard Biesheuvel [Sat, 29 Feb 2020 09:42:43 +0000 (10:42 +0100)]
OvmfPkg: use generic QEMU image loader for secure boot enabled builds
The QemuLoadImageLib implementation we currently use for all OVMF
builds copies the behavior of the QEMU loader code that precedes it,
which is to disregard UEFI secure boot policies entirely when it comes
to loading kernel images that have been specified on the QEMU command
line. This behavior deviates from ArmVirtQemu based builds, which do
take UEFI secure boot policies into account, and refuse to load images
from the command line that cannot be authenticated.
The disparity was originally due to the fact that the QEMU command line
kernel loader did not use LoadImage and StartImage at all, but this
changed recently, and now, there are only a couple of reasons left to
stick with the legacy loader:
- it permits loading images that lack a valid PE/COFF header,
- it permits loading X64 kernels on IA32 firmware running on a X64
capable system.
Since every non-authentic PE/COFF image can trivially be converted into
an image that lacks a valid PE/COFF header, the former case can simply
not be supported in a UEFI secure boot context. The latter case is highly
theoretical, given that one could easily switch to native X64 firmware in
a VM scenario.
That leaves us with little justification to use the legacy loader at all
when UEFI secure boot policies are in effect, so let's switch to the
generic loader for UEFI secure boot enabled builds.
Ard Biesheuvel [Sat, 29 Feb 2020 12:59:52 +0000 (13:59 +0100)]
OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device path
Linux v5.7 will introduce a new method to load the initial ramdisk
(initrd) from the loader, using the LoadFile2 protocol installed on a
special vendor GUIDed media device path.
Add support for this to our QEMU command line kernel/initrd loader.
Ard Biesheuvel [Sat, 29 Feb 2020 09:33:21 +0000 (10:33 +0100)]
OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib
Replace the open coded sequence to load Linux on x86 with a short and
generic sequence invoking QemuLoadImageLib, which can be provided by
a generic version that only supports the LoadImage and StartImage boot
services, and one that incorporates the entire legacy loading sequence
as well.
Ard Biesheuvel [Sat, 29 Feb 2020 00:28:45 +0000 (01:28 +0100)]
OvmfPkg: implement QEMU loader library for X86 with legacy fallback
Implement another version of QemuLoadImageLib that uses LoadImage and
StartImage, but falls back to the legacy Linux loader code if that
fails. The logic in the legacy fallback routines is identical to the
current QEMU linux loader for X64 and IA32.
Note the use of the OVMF_LOADED_X86_LINUX_KERNEL protocol for the legacy
loaded image: this makes it possible to expose the LoadImage/StartImage
abstraction for the legacy loader, using the EFI paradigm of identifying
a loaded image solely by a handle.
Ard Biesheuvel [Thu, 5 Mar 2020 10:59:57 +0000 (11:59 +0100)]
OvmfPkg: create protocol and GUID header for loaded x86 Linux kernels
In preparation of moving the legacy x86 loading to an implementation
of the QEMU load image library class, introduce a protocol header
and GUID that we will use to identify legacy loaded x86 Linux kernels
in the protocol database.
Ard Biesheuvel [Fri, 28 Feb 2020 22:15:22 +0000 (23:15 +0100)]
OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup block
On x86, the kernel image consists of a setup block and the actual kernel,
and QEMU presents these as separate blobs, whereas on disk (and in terms
of PE/COFF image signing), they consist of a single image.
So add support to our FS loader driver to expose files via the abstract
file system that consist of up to two concatenated blobs, and redefine
the kernel file so it consists of the setup and kernel blobs, on every
architecture (on non-x86, the setup block is simply 0 bytes and is
therefore ignored implicitly)
Ard Biesheuvel [Fri, 28 Feb 2020 21:38:50 +0000 (22:38 +0100)]
OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line
We have no need for exposing the kernel command line as a file,
so remove support for that. Since the remaining blobs (kernel
and initrd) are typically much larger than a page, switch to
the page based allocator for blobs at the same time.
Ard Biesheuvel [Fri, 28 Feb 2020 16:32:35 +0000 (17:32 +0100)]
ArmVirtPkg/PlatformBootManagerLib: switch to separate QEMU loader
Drop the QEMU loader file system implementation inside this library,
and switch to the separate QemuLoadImageLib library and the associated
driver to expose the kernel and initrd passed via the QEMU command line.
Ard Biesheuvel [Fri, 28 Feb 2020 16:26:54 +0000 (17:26 +0100)]
OvmfPkg: provide a generic implementation of QemuLoadImageLib
Implement QemuLoadImageLib, and make it load the image provided by the
QEMU_EFI_LOADER_FS_MEDIA_GUID/kernel device path that we implemented
in a preceding patch in a separate DXE driver, using only the standard
LoadImage and StartImage boot services.
Ard Biesheuvel [Fri, 28 Feb 2020 16:04:01 +0000 (17:04 +0100)]
OvmfPkg: introduce QemuLoadImageLib library class
Introduce the QemuLoadImageLib library class that we will instantiate
to load the kernel image passed via the QEMU command line using the
standard LoadImage boot service.
Ard Biesheuvel [Fri, 28 Feb 2020 13:58:14 +0000 (14:58 +0100)]
OvmfPkg: export abstract QEMU blob filesystem in standalone driver
Expose the existing implementation of an abstract filesystem exposing
the blobs passed to QEMU via the command line via a standalone DXE
driver.
Notable difference with the original code is the switch to a new vendor
GUIDed media device path, as opposed to a vendor GUID hardware device
path, which is not entirely appropriate for pure software constructs.
Since we are using the GetTime() runtime service in a DXE_DRIVER type
module, we need to DEPEX explicitly on gEfiRealTimeClockArchProtocolGuid.
Ard Biesheuvel [Fri, 28 Feb 2020 13:13:03 +0000 (14:13 +0100)]
OvmfPkg: add GUID for the QEMU kernel loader fs media device path
In an upcoming patch, we will introduce a separate DXE driver that
exposes the virtual SimpleFileSystem implementation that carries the
kernel and initrd passed via the QEMU command line, and a separate
library that consumes it, to be incorporated into the boot manager.
Since the GUID used for the SimpleFileSystem implementation's device
path will no longer be for internal use only, create a well defined
GUID to identify the media device path.
Laszlo Ersek [Wed, 4 Mar 2020 09:44:13 +0000 (10:44 +0100)]
ArmVirtPkg/PlatformBootManagerLib: sync Timeout with PcdPlatformBootTimeOut
Set the Timeout global variable to the same value as
PcdPlatformBootTimeOut. This way the "setvar" command in the UEFI shell,
and the "efibootmgr" command in a Linux guest, can report the front page
timeout that was requested on the QEMU command line (see
GetFrontPageTimeoutFromQemu()).
A DEBUG_VERBOSE message is logged on success too, for our QE team's sake.
Laszlo Ersek [Wed, 4 Mar 2020 09:44:12 +0000 (10:44 +0100)]
OvmfPkg/PlatformBootManagerLib: sync Timeout with PcdPlatformBootTimeOut
Set the Timeout global variable to the same value as
PcdPlatformBootTimeOut. This way the "setvar" command in the UEFI shell,
and the "efibootmgr" command in a Linux guest, can report the front page
timeout that was requested on the QEMU command line (see
GetFrontPageTimeoutFromQemu()).
A DEBUG_VERBOSE message is logged on success too, for our QE team's sake.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200304094413.19462-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Gaurav Jain [Tue, 25 Feb 2020 12:00:41 +0000 (20:00 +0800)]
MdeModulePkg/Pci: Fixed Asserts in SCT PCIIO Protocol Test.
ASSERT in PollMem_Conf, CopyMem_Conf, SetBarAttributes_Conf
Conformance Test.
SCT Test expect return as Invalid Parameter or Unsupported.
Added Checks for Function Parameters.
return Invalid or Unsupported if Check fails.
Added Checks in PciIoPollIo(), PciIoIoRead()
PciIoIoWrite()
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:25 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Do not map memory for non DMA transfer
Driver code used to map memory for DMA transfer even if host doesn't
support DMA. This is causing memory corruption when driver transfers
data using PIO. This change refactors the code to skip call to
PciIo->Map for non DMA transfers.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:24 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completion
This patch refactors the way in which the driver will check
the data transfer completion. Data transfer related
functionalities have been moved to separate function.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:23 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Read response on command completion
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed but data transfer timed out.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:22 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Enhance driver traces
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrupt
status register on failed SD command.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Ard Biesheuvel [Fri, 21 Feb 2020 10:30:31 +0000 (11:30 +0100)]
ArmPlatformPkg/PrePeiCore: replace set/way cache ops with by-VA ones
Cache maintenance operations by set/way are only intended to be used
in the context of on/offlining a core, while it has been taken out of
the coherency domain. Any use intended to ensure that the contents of
the cache have made it to main memory is unreliable, since cacheline
migration and non-architected system caches may cause these contents
to linger elsewhere, without being visible in main memory once the
MMU and caches are disabled.
In KVM on Linux, there are horrid hacks in place to ensure that such
set/way operations are trapped, and replaced with a single by-VA
clean/invalidate of the entire guest VA space once the MMU state
changes, which can be costly, and is unnecessary if we manage the
caches a bit more carefully, and perform maintenance by virtual
address only.
So let's get rid of the call to ArmInvalidateDataCache () in the
PrePeiCore startup code, and instead, invalidate the temporary RAM
region by virtual address, which is the only memory region we will
be touching with the caches and MMU both disabled and enabled,
which will lead to data corruption if data written with the MMU off
is shadowed by clean, stale cachelines that stick around when the
MMU is enabled again.
This driver depends on the gEfiCpuArchProtocolGuid protocol but does
not declare it, and so this dependency gets satisfied transitively
via ArmLib. However, ArmLib will drop this dependency as it does not
actually use it, so declare it for LcdGraphicsOutputDxe instead.
Ard Biesheuvel [Wed, 4 Mar 2020 11:45:31 +0000 (12:45 +0100)]
OvmfPkg/LinuxInitrdDynamicShellCommand: fix uninitialized status return
The Linaro CI reports:
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7:
error: variable 'Status' is used uninitialized whenever 'if' condition is
false [-Werror,-Wsometimes-uninitialized]
if (mInitrdLoadFile2Handle != NULL) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:141:10:
note: uninitialized use occurs here
return Status;
^~~~~~
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:3:
note: remove the 'if' if its condition is always true
if (mInitrdLoadFile2Handle != NULL) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:130:23:
note: initialize the variable 'Status' to silence this warning
EFI_STATUS Status;
^
= 0
Fix this by pulling the return of Status into the conditional block where
it is assigned, and return EFI_SUCCESS otherwise.
Ard Biesheuvel [Wed, 26 Feb 2020 12:06:31 +0000 (13:06 +0100)]
ArmPkg/MmCommunicationDxe: fix logic bug in DXE driver entrypoint
Commit 2fe25a74d6fee3c2 ("ArmPkg/MmCommunicationDxe: relay architected PI
events to MM context") update the ARM specific standalone MM client
driver to register for certain events in the entrypoint code, but did
so in a way that makes the entrypoint always return with an error.
Instead, return EFI_SUCCESS if registering for those events succeeds,
and back out the registrations that did succeed if one fails, and
return an error.
Fixes: 2fe25a74d6fee3c2 ("ArmPkg/MmCommunicationDxe: relay architected PI events to MM context") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Laszlo Ersek [Thu, 27 Feb 2020 21:39:03 +0000 (22:39 +0100)]
ArmPlatformPkg: convert LFs to CRLF, expand hard TABs
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this package, with:
I eliminated those suffixes that didn't stand for text files, then
blanket-converted the rest with unix2dos. Finally, picked up the actual
changes with git-add.)
At the same time, the following file had to undergo TAB expansion:
ArmPlatformPkg/Scripts/Ds5/profile.py
I used "expand -t 4", conforming to the Indentation section of PEP-8
<https://www.python.org/dev/peps/pep-0008/#indentation>.
Both the CRLF conversion and the TAB expansion are motivated by
"PatchCheck.py". "PatchCheck.py" is also the reason why CRLF conversion
and TAB expansion have to happen in the same patch.
Laszlo Ersek [Thu, 27 Feb 2020 21:39:02 +0000 (22:39 +0100)]
ArmVirtPkg: convert LFs to CRLF
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this package, with:
I eliminated those suffixes that didn't stand for text files, then
blanket-converted the rest with unix2dos. Finally, picked up the actual
changes with git-add.)
The CRLF conversion is motivated by "PatchCheck.py".
Laszlo Ersek [Thu, 27 Feb 2020 21:39:01 +0000 (22:39 +0100)]
ArmPkg: convert LFs to CRLF, expand hard TABs
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this package, with:
I eliminated those suffixes that didn't stand for text files, then
blanket-converted the rest with unix2dos. Finally, picked up the actual
changes with git-add.)
At the same time, the following three files had to undergo TAB expansion:
I used "expand -t 2", in order to stay close to the edk2 coding style
(which uses two spaces for indentation.)
Both the CRLF conversion and the TAB expansion are motivated by
"PatchCheck.py". "PatchCheck.py" is also the reason why CRLF conversion
and TAB expansion have to happen in the same patch.
Laszlo Ersek [Wed, 26 Feb 2020 22:11:56 +0000 (23:11 +0100)]
OvmfPkg/CpuS3DataDxe: enable S3 resume after CPU hotplug
During normal boot, CpuS3DataDxe allocates
- an empty CPU_REGISTER_TABLE entry in the
"ACPI_CPU_DATA.PreSmmInitRegisterTable" array, and
- an empty CPU_REGISTER_TABLE entry in the "ACPI_CPU_DATA.RegisterTable"
array,
for every CPU whose APIC ID CpuS3DataDxe can learn.
Currently EFI_MP_SERVICES_PROTOCOL is used for both determining the number
of CPUs -- the protocol reports the present-at-boot CPU count --, and for
retrieving the APIC IDs of those CPUs.
Consequently, if a CPU is hot-plugged at OS runtime, then S3 resume
breaks. That's because PiSmmCpuDxeSmm will not find the hot-added CPU's
APIC ID associated with any CPU_REGISTER_TABLE object, in the SMRAM copies
of either of the "RegisterTable" and "PreSmmInitRegisterTable" arrays. The
failure to match the hot-added CPU's APIC ID trips the ASSERT() in
SetRegister() [UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c].
If "PcdQ35SmramAtDefaultSmbase" is TRUE, then:
- prepare CPU_REGISTER_TABLE objects for all possible CPUs, not just the
present-at-boot CPUs (PlatformPei stored the possible CPU count to
"PcdCpuMaxLogicalProcessorNumber");
- use QEMU_CPUHP_CMD_GET_ARCH_ID for filling in the "InitialApicId" fields
of the CPU_REGISTER_TABLE objects.
This provides full APIC ID coverage for PiSmmCpuDxeSmm during S3 resume,
accommodating CPUs hot-added at OS runtime.
This patch is best reviewed with
$ git show -b
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-17-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:54 +0000 (23:11 +0100)]
OvmfPkg: clone CpuS3DataDxe from UefiCpuPkg
The @file comments in UefiCpuPkg/CpuS3DataDxe say,
[...] It also only supports the number of CPUs reported by the MP
Services Protocol, so this module does not support hot plug CPUs. This
module can be copied into a CPU specific package and customized if these
additional features are required. [...]
The driver is so small that the simplest way to extend it with hotplug
support is indeed to clone it at first. In this patch, customize the
driver only with the following no-op steps:
- Update copyright notices.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI files.
- Replace EFI_D_VERBOSE with DEBUG_VERBOSE, to appease "PatchCheck.py".
This patch is best reviewed with:
$ git show --find-copies-harder
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-15-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:53 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: complete root MMI handler for CPU hotplug
With the help of the Post-SMM Pen and the SMBASE relocation functions
added in the previous patches, we can now complete the root MMI handler
for CPU hotplug.
In the driver's entry point function:
- allocate the pen (in a reserved page in normal RAM),
- install the default ("first") SMI handler for hot-added CPUs (which
includes priming the exchange area between the MM Monarch and the
hot-added CPUs, i.e., shutting the APIC ID gate).
In the root MMI handler, for each hot-added CPU:
- record the APIC ID of the new CPU in CPU_HOT_PLUG_DATA,
- relocate the SMBASE of the new CPU,
- inform PiSmmCpuDxeSmm by calling
EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor().
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-14-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:51 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: introduce Post-SMM Pen for hot-added CPUs
Once a hot-added CPU finishes the SMBASE relocation, we need to pen it in
a HLT loop. Add the NASM implementation (with just a handful of
instructions, but much documentation), and some C language helper
functions.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-12-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:50 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: collect CPUs with events
Call QemuCpuhpCollectApicIds() in the root MMI handler. The APIC IDs of
the hotplugged CPUs will be used for several purposes in subsequent
patches.
For calling QemuCpuhpCollectApicIds(), pre-allocate both of its output
arrays "PluggedApicIds" and "ToUnplugApicIds" in the driver's entry point
function. The allocation size is dictated by the possible CPU count, which
we fetch from "CPU_HOT_PLUG_DATA.ArrayLength".
The CPU_HOT_PLUG_DATA structure in SMRAM is an out-of-band information
channel between this driver and PiSmmCpuDxeSmm, underlying
EFI_SMM_CPU_SERVICE_PROTOCOL.
In order to consume "CPU_HOT_PLUG_DATA.ArrayLength", extend the driver's
DEPEX to EFI_SMM_CPU_SERVICE_PROTOCOL. PiSmmCpuDxeSmm stores the address
of CPU_HOT_PLUG_DATA to "PcdCpuHotPlugDataAddress", before it produces
EFI_SMM_CPU_SERVICE_PROTOCOL.
Stash the protocol at once, as it will be needed later.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:48 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: define the QEMU_CPUHP_CMD_GET_ARCH_ID macro
QEMU commit 3a61c8db9d25 ("acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command",
2020-01-22) introduced a new command in the modern CPU hotplug register
block that lets the firmware query the arch-specific IDs (on IA32/X64: the
APIC IDs) of CPUs. Add a macro for this command value, because we'll need
it later.
At the same time, add a sanity check for the modern hotplug interface to
CpuHotplugSmm.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Add a handful of simple functions for accessing QEMU's hotplug registers
more conveniently. These functions thinly wrap some of the registers
described in "docs/specs/acpi_cpu_hotplug.txt" in the QEMU tree. The
functions hang (by design) if they encounter an internal failure.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-8-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:46 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driver
Add a new SMM driver skeleton that registers a root SMI handler, and
checks if the SMI control value (written to 0xB2) indicates a CPU hotplug
SMI.
QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU
hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other
words, control value 4 is now allocated for this purpose; introduce the
ICH9_APM_CNT_CPU_HOTPLUG macro for it.
The standard identifiers in this driver use the new MM (Management Mode)
terminology from the PI spec, not the earlier SMM (System Management Mode)
terms.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:45 +0000 (23:11 +0100)]
OvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmm
Set "PcdCpuHotPlugSupport" to TRUE, when OVMF is built with SMM_REQUIRE.
Consequences:
(1) In PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c],
resources are allocated and populated in advance for all possible
(i.e., potentially hot-added) processors, rather than only the
processors present at boot.
The possible count (called "mMaxNumberOfCpus") is set from
"PcdCpuMaxLogicalProcessorNumber"; we set the latter in
OvmfPkg/PlatformPei. (Refer to commit 83357313dd67,
"OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU
hotplug", 2020-01-29).
(2) The AddProcessor() and RemoveProcessor() member functions of
EFI_SMM_CPU_SERVICE_PROTOCOL, implemented in
"UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c", are no longer
short-circuited to EFI_UNSUPPORTED.
We'll rely on these functions in the CPU hotplug SMI handler, in a
subsequent patch.
(3) In PiCpuSmmEntry(), the address of the CPU_HOT_PLUG_DATA structure (in
SMRAM) is exposed via the dynamic-only "PcdCpuHotPlugDataAddress".
This structure is an information channel between the CPU hotplug SMI
handler, and EFI_SMM_CPU_SERVICE_PROTOCOL. Namely, at the first
"Index" where the following equality holds:
a hot-plugged CPU can be accepted, with the steps below:
(3.1) The hotplug SMI handler has to overwrite INVALID_APIC_ID with the
new CPU's APIC ID.
(3.2) The new CPU's SMBASE has to be relocated to:
CPU_HOT_PLUG_DATA.SmBase[Index]
(which was precomputed in step (1) above).
(3.3) The hotplug SMI handler is supposed to call
EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor().
Note: we need not spell out "PcdCpuHotPlugDataAddress" in the
[PcdsDynamicDefault] sections of the OVMF DSC files, just so the PCD
become dynamically settable. That's because "UefiCpuPkg.dec" declares this
PCD with [PcdsDynamic, PcdsDynamicEx] access methods *only*.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:44 +0000 (23:11 +0100)]
OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmm
With "PcdCpuSmmEnableBspElection" set to FALSE, PiSmmCpuDxeSmm always
considers the processor with index 0 to be the SMM Monarch (a.k.a. the SMM
BSP). The SMM Monarch handles the SMI for real, while the other CPUs wait
in their SMM loops.
In a subsequent patch, we want to set "PcdCpuHotPlugSupport" to TRUE. For
that, PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c] forces
us with an ASSERT() to set "PcdCpuSmmEnableBspElection" to TRUE as well.
To satisfy that expectation, we can simply remove our current
"PcdCpuSmmEnableBspElection|FALSE" setting, and inherit the default TRUE
value from "UefiCpuPkg.dec".
This causes "mSmmMpSyncData->BspIndex" in PiSmmCpuDxeSmm to lose its
static zero value (standing for CPU#0); instead it becomes (-1) in
general, and the SMM Monarch is elected anew on every SMI.
The default SMM Monarch Election is basically a race -- whichever CPU can
flip "mSmmMpSyncData->BspIndex" from (-1) to its own index, becomes king,
for handling that SMI. Refer to SmiRendezvous()
[UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c].
I consider this non-determinism less than ideal on QEMU/KVM; it would be
nice to stick with a "mostly permanent" SMM Monarch even with the Election
enabled. We can do that by implementing the PlatformSmmBspElection() API
in the SmmCpuPlatformHookLibQemu instance:
The IA32 APIC Base MSR can be read on each CPU concurrently, and it will
report the BSP bit as set only on the current Boot Service Processor. QEMU
marks CPU#0 as the BSP, by default.
Elect the current BSP, as reported by QEMU, for the SMM Monarch role.
(Note that the QEMU commit history is not entirely consistent on whether
QEMU/KVM may mark a CPU with nonzero index as the BSP:
- At tag v4.2.0, "target/i386/cpu.c" has a comment saying "We hard-wire
the BSP to the first CPU". This comment goes back to commit 6cb2996cef5e
("x86: Extend validity of bsp_to_cpu", 2010-03-04).
- Compare commit 9cb11fd7539b ("target-i386: clear bsp bit when
designating bsp", 2015-04-02) though, especially considering KVM.
Either way, this OvmfPkg patch is *not* dependent on CPU index 0; it just
takes the race on every SMI out of the game.)
One benefit of using a "mostly permanent" SMM Monarch / BSP is that we can
continue testing the SMM CPU synchronization by deterministically entering
the firmware on the BSP, vs. on an AP, from Linux guests:
$ time taskset -c 0 efibootmgr
$ time taskset -c 1 efibootmgr
(See
<https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#uefi-variable-access-test>.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c5 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Laszlo Ersek [Wed, 26 Feb 2020 22:11:43 +0000 (23:11 +0100)]
OvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkg
Clone the Null instance of SmmCpuPlatformHookLib from UefiCpuPkg to
OvmfPkg. In this patch, customize the lib instance only with the following
no-op steps:
- Replace Null/NULL references in filenames and comments with Qemu/QEMU
references.
- Update copyright notices.
- Clean up and rewrap comment blocks.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI file.
This patch is best reviewed with:
$ git show --find-copies=43 --find-copies-harder
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
projects / mirror_edk2.git / log