From patchwork Sat Sep 23 09:42:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Xin3" X-Patchwork-Id: 13396675 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B477CCE7A89 for ; Sat, 23 Sep 2023 10:16:43 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.607139.945425 (Exim 4.92) (envelope-from ) id 1qjzgh-0001Eq-17; Sat, 23 Sep 2023 10:16:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 607139.945425; Sat, 23 Sep 2023 10:16:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzgg-0001EW-Sc; Sat, 23 Sep 2023 10:16:34 +0000 Received: by outflank-mailman (input) for mailman id 607139; Sat, 23 Sep 2023 10:16:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzcQ-0000Pn-8Y for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:12:10 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a230c7b3-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:12:00 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:49 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:48 -0700 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a230c7b3-59f9-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463920; x=1726999920; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FcZc1QeKj2isPTwOBVaGNTy+si5WeOaciLFU4yv7EQo=; b=kBDL6iMjh667yNRDON91MF5Le7HkPIHIcFqrdVYme2A7L8rTndq1PFcN 2TxUBt/X0TxrZhmw2m2DgKv8lrtQARhfOWHn0MY2rpYebOL5Hhi2Y4+rw CSNLF4BLZkDwpA6w62/BvdE4UbyFNkSxJYcBg+/M5Pky0hw/9/fvZDj2d nD9lIbHCYR7vAinR3DHrcM8WtmjNo8JjfoTa8YtWjhuK8xFV1B/WN/Jup f1UKgdDB4EnXzXXW8XPRLINTh0n+KefTJuTi14eNMPvCArEO7BnCD/uuk XhstGRQmj8dP4HhI1JoOQUWScCXQ+4eO0di7NNAM/MtqZnR4Fq4HI3Ni+ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492388" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492388" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388193" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388193" 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 v11 26/37] x86/fred: Add a NMI entry stub for FRED Date: Sat, 23 Sep 2023 02:42:01 -0700 Message-Id: <20230923094212.26520-27-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 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++;