From nobody Sat Apr 11 07:07:34 2026 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 0ED0DC678D4 for ; Thu, 2 Mar 2023 05:51:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229915AbjCBFvg (ORCPT ); Thu, 2 Mar 2023 00:51:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229881AbjCBFu7 (ORCPT ); Thu, 2 Mar 2023 00:50:59 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19A794E5C0; Wed, 1 Mar 2023 21:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1677736257; x=1709272257; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=siTNXpO7BJ/4zV0VfXO5tCEXqrBwC+DhXoQqxTjs92s=; b=YZM7dUQSruF79mZdIQyCNWfnwadP0uDxdF0WBHjIW5oeXtZgg2CtRBk0 cx6h94t7OcRsh4JjokGiovC+M7UP0NxswS+j7Jch9gzb6JR9Uh6BGXzKb KXffb+c6QHo6ki9UG6wX9FChpO3FwetLuSCTuLhDfzDyD1IFBDbWvz5eq UUkbGAShraOvtLHTlnQg+nkjHiHYmclbU7ZmCvWAl6HIqu1oBhN9+/r0+ K552+2zhnoqESYQFnq2h3XFDol9ioHo9+Iq6CCuA9S5IsK8Bb2fFLT8Xk xfF14JnV6jh1yc4ZDrKSghbQE4j1CyAoi2+/YmFsT2sl/jb0yTL5JSd8S g==; X-IronPort-AV: E=McAfee;i="6500,9779,10636"; a="420887141" X-IronPort-AV: E=Sophos;i="5.98,226,1673942400"; d="scan'208";a="420887141" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2023 21:50:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10636"; a="920530931" X-IronPort-AV: E=Sophos;i="5.98,226,1673942400"; d="scan'208";a="920530931" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga006.fm.intel.com with ESMTP; 01 Mar 2023 21:50:49 -0800 From: Xin Li To: linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, andrew.cooper3@citrix.com, seanjc@google.com, pbonzini@redhat.com, ravi.v.shankar@intel.com Subject: [PATCH v4 19/34] x86/fred: add a NMI entry stub for FRED Date: Wed, 1 Mar 2023 21:24:56 -0800 Message-Id: <20230302052511.1918-20-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230302052511.1918-1-xin3.li@intel.com> References: <20230302052511.1918-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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/include/asm/fred.h | 1 + arch/x86/kernel/nmi.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+) diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h index 633dd9e6a68e..f928a03082af 100644 --- a/arch/x86/include/asm/fred.h +++ b/arch/x86/include/asm/fred.h @@ -94,6 +94,7 @@ static __always_inline unsigned long fred_event_data(stru= ct pt_regs *regs) #define DEFINE_FRED_HANDLER(f) noinstr DECLARE_FRED_HANDLER(f) typedef DECLARE_FRED_HANDLER((*fred_handler)); =20 +DECLARE_FRED_HANDLER(fred_exc_nmi); DECLARE_FRED_HANDLER(fred_exc_debug); DECLARE_FRED_HANDLER(fred_exc_page_fault); =20 diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c index 776f4b1e395b..1deedfd6de69 100644 --- a/arch/x86/kernel/nmi.c +++ b/arch/x86/kernel/nmi.c @@ -34,6 +34,7 @@ #include #include #include +#include =20 #define CREATE_TRACE_POINTS #include @@ -643,6 +644,33 @@ void nmi_backtrace_stall_check(const struct cpumask *b= tp) =20 #endif =20 +#ifdef CONFIG_X86_FRED +DEFINE_FRED_HANDLER(fred_exc_nmi) +{ + /* + * With FRED, CR2 and DR6 are pushed atomically on faults, + * so we don't have to worry about saving and restoring them. + * Breakpoint faults nest, so assume it is OK to leave DR7 + * enabled. + */ + irqentry_state_t irq_state =3D irqentry_nmi_enter(regs); + + /* + * VM exits induced by NMIs keep NMI blocked, and we do + * "int $2" to reinject the NMI w/ NMI kept being blocked. + * However "int $2" doesn't set the nmi bit in the FRED + * stack frame, so we explicitly set it to make sure a + * later ERETS will unblock NMI immediately. + */ + regs->nmi =3D 1; + + inc_irq_stat(__nmi_count); + default_do_nmi(regs); + + irqentry_nmi_exit(regs, irq_state); +} +#endif + void stop_nmi(void) { ignore_nmis++; --=20 2.34.1