On 15/11/2016 02:50, Laszlo Ersek wrote:
> The generic edk2 SMM infrastructure prefers
> EFI_SMM_CONTROL2_PROTOCOL.Trigger() to inject an SMI on each processor. If
> Trigger() only brings the current processor into SMM, then edk2 handles it
> in the following ways:
>
> (1) If Trigger() is executed by the BSP (which is guaranteed before
> ExitBootServices(), but is not necessarily true at runtime), then:
>
> (a) If edk2 has been configured for "traditional" SMM synchronization,
> then the BSP sends directed SMIs to the APs with APIC delivery,
> bringing them into SMM individually. Then the BSP runs the SMI
> handler / dispatcher.
>
> (b) If edk2 has been configured for "relaxed" SMM synchronization,
> then the APs that are not already in SMM are not brought in, and
> the BSP runs the SMI handler / dispatcher.
>
> (2) If Trigger() is executed by an AP (which is possible after
> ExitBootServices(), and can be forced e.g. by "taskset -c 1
> efibootmgr"), then the AP in question brings in the BSP with a
> directed SMI, and the BSP runs the SMI handler / dispatcher.
>
> The smaller problem with (1a) and (2) is that the BSP and AP
> synchronization is slow. For example, the "taskset -c 1 efibootmgr"
> command from (2) can take more than 3 seconds to complete, because
> efibootmgr accesses non-volatile UEFI variables intensively.
>
> The larger problem is that QEMU's current behavior diverges from the
> behavior usually seen on physical hardware, and that keeps exposing
> obscure corner cases, race conditions and other instabilities in edk2,
> which generally expects / prefers a software SMI to affect all CPUs at
> once.
>
> Therefore introduce a special APM_STS value (0x51) that causes QEMU to
> inject the SMI on all VCPUs. OVMF's EFI_SMM_CONTROL2_PROTOCOL.Trigger()
> can utilize this to accommodate edk2's preference about "broadcast" SMI.
>
> SeaBIOS uses values 0x00 and 0x01 for APM_STS (called PORT_SMI_STATUS in
> the SeaBIOS code), so this change should be transparent to it.
>
> While the original posting of this patch
> <http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05658.html>
> only intended to speed up (2), based on our recent "stress testing" of SMM
> this patch actually provides functional improvements. (There are no code
> changes relative to the original posting.)
>
> Cc: "Michael S. Tsirkin" <m...@redhat.com>
> Cc: Paolo Bonzini <pbonz...@redhat.com>
> Also-suggested-by: Paolo Bonzini <pbonz...@redhat.com>
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
I'm queuing this for 2.8, but I have a question---should this feature be
detectable, and if so how?
Paolo
> ---
> hw/isa/lpc_ich9.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 10d1ee8b9310..f2fe644fdaa4 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -372,6 +372,8 @@ void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool
> smm_enabled)
>
> /* APM */
>
> +#define QEMU_ICH9_APM_STS_BROADCAST_SMI 'Q'
> +
> static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
> {
> ICH9LPCState *lpc = arg;
> @@ -386,7 +388,15 @@ static void ich9_apm_ctrl_changed(uint32_t val, void
> *arg)
>
> /* SMI_EN = PMBASE + 30. SMI control and enable register */
> if (lpc->pm.smi_en & ICH9_PMIO_SMI_EN_APMC_EN) {
> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
> + if (lpc->apm.apms == QEMU_ICH9_APM_STS_BROADCAST_SMI) {
> + CPUState *cs;
> +
> + CPU_FOREACH(cs) {
> + cpu_interrupt(cs, CPU_INTERRUPT_SMI);
> + }
> + } else {
> + cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
> + }
> }
> }
>
>
