From patchwork Tue Mar 7 02:39:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Xin3" X-Patchwork-Id: 65220 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2209818wrd; Mon, 6 Mar 2023 19:07:54 -0800 (PST) X-Google-Smtp-Source: AK7set/r0JPBfmhAY0ZX1kv+4KVzwL42tIPfAjB6MJr6qoojMBKFWGFCrqOuLpvBf1fRuICHNsdx X-Received: by 2002:a17:90b:17c4:b0:234:e0c:caaa with SMTP id me4-20020a17090b17c400b002340e0ccaaamr13805716pjb.6.1678158474055; Mon, 06 Mar 2023 19:07:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678158474; cv=none; d=google.com; s=arc-20160816; b=b7ZMErXWcw99viYxEgWJRoYVezh+R06z6MoSk/byMDT9Zgkyk0JWB4SoXxnrMaqIip bMho0gsd9tqCIhJsc3jofOXq0G+LE0NJPmUPpIaaxw5dzDzTq9o5TsNcC7iR2cvgbOxC e7SgqKVxZTNOTZn7po5PR/RmLGJmmUErvSfGR5WBniN15LBURDX9K2YawH/PV6GiY3DQ 3afrurHAXr3zPcI2IP/jEr1HrG1zvnUpZal95qjlY0Gh9/EDPkdDQRQ1lgvf8YaZl2tc kwCEQTDiGTwiT+iS1qzbaUNrblIe8pyhYqBtaVp7ybnJhLUpf4jjX63pbUcE9KHcosLC UvCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=h+68pRnmJGZH53rrxJ5ePUtJhcj/U+0E+Y2T3Oe3Zns=; b=Gx4dnSGCQ4n5b3nKptEVuRPagjCkAcDY+co8L0F2ZgLnqxBxZO+xrWq0sPuiXAxA60 7r4Skw9PW9bfH0E0l4BxF8J400F8CyODp1Jhb7rdROfr2PjRiwKhduJdCVpJCoZYK07v a69zz2BL3oFptGxqEv0RfzUUoQ2UyxWefsaHpstfwu86f+geuYAW4WdNZW3cFAcdv1hN lvi3xlHBro+wAl4yukyspdG4jV1Q3vyNTDlPTGgL2kmOKzUr3YWfuy8pJF8zM+2nALS1 svEAa0cVLHUYCdt3Q+dWJMcCnPIu1t1FkYYAUBGxEYJ9U3mt9F1K7d+QdJRKO636I8Yl 6wFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MNhw3qM1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i2-20020a17090ac40200b0022c5524d76dsi236091pjt.24.2023.03.06.19.07.41; Mon, 06 Mar 2023 19:07:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MNhw3qM1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230344AbjCGDGu (ORCPT + 99 others); Mon, 6 Mar 2023 22:06:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230337AbjCGDF7 (ORCPT ); Mon, 6 Mar 2023 22:05:59 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BEA23CE31; Mon, 6 Mar 2023 19:05: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=1678158331; x=1709694331; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=siTNXpO7BJ/4zV0VfXO5tCEXqrBwC+DhXoQqxTjs92s=; b=MNhw3qM1aL+GklOWcAb2uVDBdjdHlCaCPJtDJRW7BIfviYYd+CEicXBM vS8ES3rcFvIEO1dwua9d5H0pfSfKC/BjJGf0gL94L2iygl0PLtDhj92kx SEHLImRDl2EG2rLq73gPcOv/Awuwj2GBYJ00WdvWyjyTm6Ee/ZcQPY0OE 8TCCEfJcfvaZ/11mHiZQMVzQEXGdlAfVBrYHsdurzjtbErXmH/UVla+IX bcl5SPEKBESO61V9zKvnWT+3xYb+2kIiBzCm29FgnsUIK+FEGxNB2fJ2a gr1pZz0vHial8j+YqZg4n99PsChZSyG/gClnPiSKkukU2tV+Jp9WiHGHj A==; X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="338072486" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="338072486" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2023 19:05:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="676409846" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="676409846" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga002.jf.intel.com with ESMTP; 06 Mar 2023 19:05:17 -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 v5 19/34] x86/fred: add a NMI entry stub for FRED Date: Mon, 6 Mar 2023 18:39:31 -0800 Message-Id: <20230307023946.14516-20-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230307023946.14516-1-xin3.li@intel.com> References: <20230307023946.14516-1-xin3.li@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759676700078443727?= X-GMAIL-MSGID: =?utf-8?q?1759676700078443727?= 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(struct pt_regs *regs) #define DEFINE_FRED_HANDLER(f) noinstr DECLARE_FRED_HANDLER(f) typedef DECLARE_FRED_HANDLER((*fred_handler)); +DECLARE_FRED_HANDLER(fred_exc_nmi); DECLARE_FRED_HANDLER(fred_exc_debug); DECLARE_FRED_HANDLER(fred_exc_page_fault); 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 #define CREATE_TRACE_POINTS #include @@ -643,6 +644,33 @@ void nmi_backtrace_stall_check(const struct cpumask *btp) #endif +#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 = 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 = 1; + + inc_irq_stat(__nmi_count); + default_do_nmi(regs); + + irqentry_nmi_exit(regs, irq_state); +} +#endif + void stop_nmi(void) { ignore_nmis++;