diff options
author | Laszlo Ersek <lersek@redhat.com> | 2015-11-30 18:46:50 +0000 |
---|---|---|
committer | lersek <lersek@Edk2> | 2015-11-30 18:46:50 +0000 |
commit | bb0f18b0bce682f6780af997de45bcef146c11ca (patch) | |
tree | ef5d30603b3d0f1888e23abba8007e15a416e23c /OvmfPkg/OvmfPkgIa32.dsc | |
parent | 9b1e378811ff730fe4e5bbbba294ea74ef76a915 (diff) | |
download | edk2-platforms-bb0f18b0bce682f6780af997de45bcef146c11ca.tar.xz |
OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 ms
This patch complements the previous one, "OvmfPkg: use relaxed AP SMM
synchronization mode". While that patch focuses on the case when the SMI
is raised synchronously by the BSP, on the BSP:
BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
SmmWaitForApArrival() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c]
this patch concerns itself with the case when it is one of the APs that
raises (and sees delivered) the synchronous SMI:
APHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c]
Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of
PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default
value is 1 second). If the BSP doesn't show up in SMM within that
interval, then the AP brings it in with a directed SMI, and waits for the
BSP again for PcdCpuSmmApSyncTimeout microseconds.
Although during boot services, SmmControl2DxeTrigger() is only called by
the BSP, at runtime the OS can invoke runtime services from an AP (it can
even be forced with "taskset -c 1 efibootmgr"). Because on QEMU
SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP
and AP alike), the first interval above times out invariably in such cases
-- the BSP never shows up before the AP calls it in.
In order to mitigate the performance penalty, decrease
PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For
comparison, Vlv2TbltDevicePkg sets 1 ms.)
NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch
and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode")
should be reverted, and SmmControl2DxeTrigger() should be adjusted
instead.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19059 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'OvmfPkg/OvmfPkgIa32.dsc')
-rw-r--r-- | OvmfPkg/OvmfPkgIa32.dsc | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 30ffa9caff..7259bf7fc9 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -377,6 +377,7 @@ !if $(SMM_REQUIRE) == TRUE
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
!endif
!if $(SECURE_BOOT_ENABLE) == TRUE
|