From mboxrd@z Thu Jan 1 00:00:00 1970 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 7B815C4167B for ; Tue, 5 Dec 2023 11:22:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442290AbjLELWh (ORCPT ); Tue, 5 Dec 2023 06:22:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1442151AbjLELVh (ORCPT ); Tue, 5 Dec 2023 06:21:37 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4AD01B2; Tue, 5 Dec 2023 03:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701775293; x=1733311293; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vHkfUOkHLHmL9MW/AMzgDgLZBnOiSQn6Z3TVJI+bGO8=; b=CRXWHQ4H81R0cvmUGLucDD3HU24fq6oAs1lZ4glpJWSS19DCRrkAzXnJ touVoPG4zy5jKPfxLb2qP3YE3LRaH3WTCIUf1nYGXAi4jkmok+JG6qKWm LYY/Gd+wQypf5/NSZJykuASt5OkDl/lzJ0dKlcKHS5VybDlAjtTMMudg6 NXho0s7G5y4XSEHk3Uazcs/vaG4NWft7BIgwpvaTBd2nZBIEC8GZHJB8U r3BVx8Z8eMRqTfjTSW/Vf8LojPAiJbTpqYUXIgDIgc5b/BEx5VO3Ftvti 2fxC+pBs1WU7Z+XN59UX/XWbQQv5RRMsXNfzlfkcc3ncpASd9c/UR7QRK w==; X-IronPort-AV: E=McAfee;i="6600,9927,10914"; a="942594" X-IronPort-AV: E=Sophos;i="6.04,252,1695711600"; d="scan'208";a="942594" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2023 03:21:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10914"; a="1018192984" X-IronPort-AV: E=Sophos;i="6.04,252,1695711600"; d="scan'208";a="1018192984" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga006.fm.intel.com with ESMTP; 05 Dec 2023 03:21:23 -0800 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, shan.kang@intel.com Subject: [PATCH v13 24/35] x86/fred: Add a NMI entry stub for FRED Date: Tue, 5 Dec 2023 02:50:13 -0800 Message-ID: <20231205105030.8698-25-xin3.li@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20231205105030.8698-1-xin3.li@intel.com> References: <20231205105030.8698-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 17e955ab69fe..56350d839e44 100644 --- a/arch/x86/kernel/nmi.c +++ b/arch/x86/kernel/nmi.c @@ -35,6 +35,7 @@ #include #include #include +#include #define CREATE_TRACE_POINTS #include @@ -651,6 +652,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++; -- 2.43.0