Reviewed-by: Michael Kinney <michael.d.kin...@intel.com>

>-----Original Message-----
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, November 03, 2015 1:01 PM
>To: edk2-de...@ml01.01.org
>Cc: Paolo Bonzini; Justen, Jordan L; Kinney, Michael D
>Subject: [PATCH v4 25/41] 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 <pbonz...@redhat.com>
>Cc: Jordan Justen <jordan.l.jus...@intel.com>
>Cc: Michael Kinney <michael.d.kin...@intel.com>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Laszlo Ersek <ler...@redhat.com>
>---
>
>Notes:
>    v4:
>    - new in v4
>
> OvmfPkg/OvmfPkgIa32.dsc    | 1 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
> OvmfPkg/OvmfPkgX64.dsc     | 1 +
> 3 files changed, 3 insertions(+)
>
>diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>index 850c2ab..f9b7af7 100644
>--- a/OvmfPkg/OvmfPkgIa32.dsc
>+++ b/OvmfPkg/OvmfPkgIa32.dsc
>@@ -406,6 +406,7 @@ [PcdsFixedAtBuild]
>
> !if $(SMM_REQUIRE) == TRUE
>   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
> !endif
>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>index 48960a5..028c21a 100644
>--- a/OvmfPkg/OvmfPkgIa32X64.dsc
>+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>@@ -412,6 +412,7 @@ [PcdsFixedAtBuild]
> [PcdsFixedAtBuild.X64]
> !if $(SMM_REQUIRE) == TRUE
>   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
> !endif
>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>index bb93a72..5ee17ff 100644
>--- a/OvmfPkg/OvmfPkgX64.dsc
>+++ b/OvmfPkg/OvmfPkgX64.dsc
>@@ -411,6 +411,7 @@ [PcdsFixedAtBuild]
>
> !if $(SMM_REQUIRE) == TRUE
>   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
> !endif
>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>--
>1.8.3.1
>

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to