From patchwork Tue Dec 20 06:36:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Xin3" X-Patchwork-Id: 34930 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp2813671wrn; Mon, 19 Dec 2022 23:04:08 -0800 (PST) X-Google-Smtp-Source: AA0mqf4UWjADUs05LY/4nCspsGIeKkjEleDU13opEFR0i8csExuT89UGjxwPu/eQVwH86B3SRGdJ X-Received: by 2002:aa7:8492:0:b0:576:ebfe:e9c1 with SMTP id u18-20020aa78492000000b00576ebfee9c1mr43619821pfn.20.1671519848392; Mon, 19 Dec 2022 23:04:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671519848; cv=none; d=google.com; s=arc-20160816; b=imxLkeWj06cNUmsoHqRnCUm1IZnuZrqeV3YJleSsJSQg1hWEqGar4MtioyjG41t55Y G57Il1XgFCXJuXfJX19h4BUEeUlXDc8lmkO8ALow1/HsZ7KXTnD0gESVMG1yysnnc/IE t0mNGIouowP1sdELuk2xb8b9ZsaGzLCMJzwWc4pbgx5SjUpUptTw2RmtclyWKvIbYqO5 WJjrQX2591geXJDU/xeSiEfMYLPp1n63HMkvkcQJP//NRe6UE4bmLhidf7/UKQYS2EiK yVOQGcH19YTNhfsj+2BHWD1/z80Yiw+25eU2TjP5FTVjO7wnxDQk9hwb93CBhtPOLtTY YH+w== 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=1CIBAKqSKs6F1CajRY1NJy2ezW1INpoAD5cl0fdjCB8=; b=O9eBc+dGCU2ajHNFk0KvBtC0t72U+6qb0zyDeEWzkvgbzDfo+GVtplXIJkb2fwhkVQ 0LPxQ0kmF1PqO7NVrVsCbLPG0kyLXu7m8a8e6rqCic8NoJQNMycZDkyiAPcqcjRR3v35 vEwOUP4D87HyVCvrZjbk8NJXyb2jxCHmAB78iblTvpAd8ePU4qFmxlwBo+WiNyYtJgnD SD+wHyEchyYMZjHjhwa0mrZXYDJEqzD8Jw5LKFjUCIsVnxacZ3o/jysBRrWnb88j2TtJ vcGUIwB5IRBbi15BajjaklhBseWmEn047taZzITxjosPk1MvomWFPAptNra1RvHrG8To H+Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c8aMwiG4; 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 x1-20020aa79401000000b00576dee77c98si12703554pfo.299.2022.12.19.23.03.54; Mon, 19 Dec 2022 23:04:08 -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=c8aMwiG4; 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 S233630AbiLTHDY (ORCPT + 99 others); Tue, 20 Dec 2022 02:03:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233250AbiLTHBi (ORCPT ); Tue, 20 Dec 2022 02:01:38 -0500 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82CEBDEE4; Mon, 19 Dec 2022 23:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1671519697; x=1703055697; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GhhTMX7j/CtwNJ9iPX8pNCtQRNtO0Tx2XqCNn06W3ZE=; b=c8aMwiG4MCZOmIKLUmp80NE66dol0Bu5EP/TL1jURiocA6OYEH95dtGb WSCZkx/2QQuL4y25KcpR3DLNugeKENnhMM/WoLDFkOYD9DSXtkGXqz5Gn +huJSNtRdYRoWCfMc85rmcYSQfrU4UiDyfkBEy9UonxTBYjGe4SQ99lYq 226oQu+9Z5vmzhRpLaks11rTCxNHOTKs3c8sQN+LB9ABqVlatS0eQT7g9 ZTbzjBxebrz6vJGc5FcOqG+Pembx4nB+UA60ropI9WP1yvMyvXtH5f9Uc QJki4gw5n7iGDD609UBcEmQNZ3btuziziG65+Wnp8hnRY0jJhXWXZQKRC w==; X-IronPort-AV: E=McAfee;i="6500,9779,10566"; a="302972067" X-IronPort-AV: E=Sophos;i="5.96,258,1665471600"; d="scan'208";a="302972067" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Dec 2022 23:01:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10566"; a="644326494" X-IronPort-AV: E=Sophos;i="5.96,258,1665471600"; d="scan'208";a="644326494" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga007.jf.intel.com with ESMTP; 19 Dec 2022 23:01:14 -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: [RFC PATCH 18/32] x86/fred: add a debug fault entry stub for FRED Date: Mon, 19 Dec 2022 22:36:44 -0800 Message-Id: <20221220063658.19271-19-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221220063658.19271-1-xin3.li@intel.com> References: <20221220063658.19271-1-xin3.li@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE, SPF_NONE 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?1752715596298955766?= X-GMAIL-MSGID: =?utf-8?q?1752715596298955766?= From: "H. Peter Anvin (Intel)" Add a debug fault entry stub for FRED. On a FRED system, the debug trap status information (DR6) is passed on the stack, to avoid the problem of transient state. Furthermore, FRED transitions avoid a lot of ugly corner cases the handling of which can, and should be, skipped. The FRED debug trap status information saved on the stack differs from DR6 in both stickiness and polarity; it is exactly what debug_read_clear_dr6() returns, and exc_debug_user()/exc_debug_kernel() expect. Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li --- arch/x86/include/asm/fred.h | 1 + arch/x86/kernel/traps.c | 61 ++++++++++++++++++++++++++----------- 2 files changed, 45 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h index 38a90eae7c0f..3089d1c70771 100644 --- a/arch/x86/include/asm/fred.h +++ b/arch/x86/include/asm/fred.h @@ -92,6 +92,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_debug); DECLARE_FRED_HANDLER(fred_exc_page_fault); #endif /* __ASSEMBLY__ */ diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 99386836b02e..b0ee83bab9e6 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -47,6 +47,7 @@ #include #include #include +#include #include #include #include @@ -1020,22 +1021,9 @@ static bool notify_debug(struct pt_regs *regs, unsigned long *dr6) return false; } -static __always_inline void exc_debug_kernel(struct pt_regs *regs, - unsigned long dr6) +static __always_inline void debug_kernel_common(struct pt_regs *regs, + unsigned long dr6) { - /* - * Disable breakpoints during exception handling; recursive exceptions - * are exceedingly 'fun'. - * - * Since this function is NOKPROBE, and that also applies to - * HW_BREAKPOINT_X, we can't hit a breakpoint before this (XXX except a - * HW_BREAKPOINT_W on our stack) - * - * Entry text is excluded for HW_BP_X and cpu_entry_area, which - * includes the entry stack is excluded for everything. - */ - unsigned long dr7 = local_db_save(); - irqentry_state_t irq_state = irqentry_nmi_enter(regs); instrumentation_begin(); /* @@ -1062,7 +1050,8 @@ static __always_inline void exc_debug_kernel(struct pt_regs *regs, * Catch SYSENTER with TF set and clear DR_STEP. If this hit a * watchpoint at the same time then that will still be handled. */ - if ((dr6 & DR_STEP) && is_sysenter_singlestep(regs)) + if (!cpu_feature_enabled(X86_FEATURE_FRED) && + (dr6 & DR_STEP) && is_sysenter_singlestep(regs)) dr6 &= ~DR_STEP; /* @@ -1089,8 +1078,28 @@ static __always_inline void exc_debug_kernel(struct pt_regs *regs, regs->flags &= ~X86_EFLAGS_TF; out: instrumentation_end(); - irqentry_nmi_exit(regs, irq_state); +} + +static __always_inline void exc_debug_kernel(struct pt_regs *regs, + unsigned long dr6) +{ + /* + * Disable breakpoints during exception handling; recursive exceptions + * are exceedingly 'fun'. + * + * Since this function is NOKPROBE, and that also applies to + * HW_BREAKPOINT_X, we can't hit a breakpoint before this (XXX except a + * HW_BREAKPOINT_W on our stack) + * + * Entry text is excluded for HW_BP_X and cpu_entry_area, which + * includes the entry stack is excluded for everything. + */ + unsigned long dr7 = local_db_save(); + irqentry_state_t irq_state = irqentry_nmi_enter(regs); + + debug_kernel_common(regs, dr6); + irqentry_nmi_exit(regs, irq_state); local_db_restore(dr7); } @@ -1179,6 +1188,24 @@ DEFINE_IDTENTRY_DEBUG_USER(exc_debug) { exc_debug_user(regs, debug_read_clear_dr6()); } + +# ifdef CONFIG_X86_FRED +DEFINE_FRED_HANDLER(fred_exc_debug) +{ + /* + * The FRED debug information saved onto stack differs from + * DR6 in both stickiness and polarity; it is exactly what + * debug_read_clear_dr6() returns. + */ + unsigned long dr6 = fred_event_data(regs); + + if (user_mode(regs)) + exc_debug_user(regs, dr6); + else + debug_kernel_common(regs, dr6); +} +# endif /* CONFIG_X86_FRED */ + #else /* 32 bit does not have separate entry points. */ DEFINE_IDTENTRY_RAW(exc_debug)