From patchwork Thu Dec 1 17:06:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 701610 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tV3kS1M77z9sDB for ; Fri, 2 Dec 2016 04:12:32 +1100 (AEDT) Received: from localhost ([::1]:57615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCUuL-0004gY-F2 for incoming@patchwork.ozlabs.org; Thu, 01 Dec 2016 12:12:29 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCUoq-00088R-FH for qemu-devel@nongnu.org; Thu, 01 Dec 2016 12:06:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCUop-0006sQ-D9 for qemu-devel@nongnu.org; Thu, 01 Dec 2016 12:06:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45620) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCUop-0006s3-5W for qemu-devel@nongnu.org; Thu, 01 Dec 2016 12:06:47 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 75E909023C for ; Thu, 1 Dec 2016 17:06:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-138.phx2.redhat.com [10.3.116.138]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB1H6SN2022984; Thu, 1 Dec 2016 12:06:44 -0500 From: Laszlo Ersek To: qemu devel list Date: Thu, 1 Dec 2016 18:06:23 +0100 Message-Id: <20161201170624.26496-7-lersek@redhat.com> In-Reply-To: <20161201170624.26496-1-lersek@redhat.com> References: <20161201170624.26496-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 01 Dec 2016 17:06:46 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v4 6/7] hw/isa/lpc_ich9: add broadcast SMI feature X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Igor Mammedov , Paolo Bonzini , Gerd Hoffmann , "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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 the "broadcast SMI" feature (ICH9_LPC_SMI_F_BROADCAST) that causes QEMU to inject the SMI on all VCPUs. While the original posting of this patch only intended to speed up (2), based on our recent "stress testing" of SMM this patch actually provides functional improvements. Cc: "Michael S. Tsirkin" Cc: Gerd Hoffmann Cc: Igor Mammedov Cc: Paolo Bonzini Signed-off-by: Laszlo Ersek --- include/hw/i386/ich9.h | 3 +++ hw/isa/lpc_ich9.c | 9 ++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h index 33142eb37252..e914b3f56fd8 100644 --- a/include/hw/i386/ich9.h +++ b/include/hw/i386/ich9.h @@ -248,6 +248,9 @@ Object *ich9_lpc_find(void); #define ICH9_SMB_XMIT_SLVA 0x04 #define ICH9_SMB_HST_D0 0x05 #define ICH9_SMB_HST_D1 0x06 #define ICH9_SMB_HOST_BLOCK_DB 0x07 +/* bits used in fw_cfg SMI feature negotiation */ +#define ICH9_LPC_SMI_F_BROADCAST (UINT64_C(1) << 0) + #endif /* HW_ICH9_H */ diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c index ee1fa553bfee..6e9edbe62226 100644 --- a/hw/isa/lpc_ich9.c +++ b/hw/isa/lpc_ich9.c @@ -437,11 +437,18 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) return; } /* 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->smi_negotiated_features & ICH9_LPC_SMI_F_BROADCAST) { + CPUState *cs; + CPU_FOREACH(cs) { + cpu_interrupt(cs, CPU_INTERRUPT_SMI); + } + } else { + cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); + } } } /* config:PMBASE */ static void