From patchwork Tue Oct 3 06:24:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Xin3" X-Patchwork-Id: 13406890 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DC97E7542E for ; Tue, 3 Oct 2023 06:56:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230356AbjJCG4c (ORCPT ); Tue, 3 Oct 2023 02:56:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239464AbjJCG40 (ORCPT ); Tue, 3 Oct 2023 02:56:26 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DCF21B2; Mon, 2 Oct 2023 23:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696316129; x=1727852129; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FcZc1QeKj2isPTwOBVaGNTy+si5WeOaciLFU4yv7EQo=; b=YabQmiE2rUx4dErSR37M2EqgFHIHXiG0Ka0awdSpRllK5SHyst4X/ti6 H5w7T0rGchpemXK3ghfDnpqkC364Jcb/62rEpV0c8Qn7O2I2+InHUarSe JwcT3UJpFWUf9BPTip1QdrjfRDE7dcTi4V3W5WBDeP8SylO/k6Dm0Pwyi ldBIyZdbNfIWDhLZq3Z/8QaS6bN+2gfUdiMJbxlHSZmGhV+I1e0FeyzHM Uenc3iNyS/5EZ/QB8xVlaPWrYIWb5wdO09lyY73WvBWo0fwn+UMnXkU4m rsNBGqzpI3MRSIXskDnvlpnIBGV8NwJ1tDhk2Uo7hgUW3wdHTmMVIW1LS A==; X-IronPort-AV: E=McAfee;i="6600,9927,10851"; a="367858229" X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="367858229" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2023 23:54:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10851"; a="1081900982" X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="1081900982" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga005.fm.intel.com with ESMTP; 02 Oct 2023 23:54:47 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com, nik.borisov@suse.com Subject: [PATCH v12 26/37] x86/fred: Add a NMI entry stub for FRED Date: Mon, 2 Oct 2023 23:24:47 -0700 Message-Id: <20231003062458.23552-27-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231003062458.23552-1-xin3.li@intel.com> References: <20231003062458.23552-1-xin3.li@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-edac@vger.kernel.org From: "H. Peter Anvin (Intel)" On a FRED system, NMIs nest both with themselves and faults, transient information is saved into the stack frame, and NMI unblocking only happens when the stack frame indicates that so should happen. Thus, the NMI entry stub for FRED is really quite small... Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/nmi.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c index a0c551846b35..58843fdf5cd0 100644 --- a/arch/x86/kernel/nmi.c +++ b/arch/x86/kernel/nmi.c @@ -34,6 +34,7 @@ #include #include #include +#include #define CREATE_TRACE_POINTS #include @@ -643,6 +644,33 @@ void nmi_backtrace_stall_check(const struct cpumask *btp) #endif +#ifdef CONFIG_X86_FRED +/* + * With FRED, CR2/DR6 is pushed to #PF/#DB stack frame during FRED + * event delivery, i.e., there is no problem of transient states. + * And NMI unblocking only happens when the stack frame indicates + * that so should happen. + * + * Thus, the NMI entry stub for FRED is really straightforward and + * as simple as most exception handlers. As such, #DB is allowed + * during NMI handling. + */ +DEFINE_FREDENTRY_NMI(exc_nmi) +{ + irqentry_state_t irq_state; + + if (IS_ENABLED(CONFIG_SMP) && arch_cpu_is_offline(smp_processor_id())) + return; + + irq_state = irqentry_nmi_enter(regs); + + inc_irq_stat(__nmi_count); + default_do_nmi(regs); + + irqentry_nmi_exit(regs, irq_state); +} +#endif + void stop_nmi(void) { ignore_nmis++;