Received: by 2002:a05:7412:3290:b0:fa:6e18:a558 with SMTP id ev16csp138764rdb; Thu, 25 Jan 2024 10:25:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IFsrmwN7l1XJVIbGPlfNxYbAn8LCiwyPewDiLzIkIlWaL4FB/pTEsuhYpUMNsJal+qcvYcE X-Received: by 2002:a17:902:74c1:b0:1d7:41f4:be8e with SMTP id f1-20020a17090274c100b001d741f4be8emr124312plt.65.1706207125813; Thu, 25 Jan 2024 10:25:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706207125; cv=pass; d=google.com; s=arc-20160816; b=VhwZAfEkJayl98sjiiFPR/OKPT5eFZx9A08EYhahctQmOy1jjoGQbMBzED3p6ofi+d ufprkzr8oks++m3ZaX8Wl3hH33Z+KMeYHfL3EbHCXoTnoWkU9E25UcHOlDeouoE0olvr HMFIXw+WZvC9nJ8nfIB51JIQzahmi2CZch5HXsNslbM0j4CISP9o9oAxijyWuvdJzFl0 6gSK+7mpkNWqagSx3Uj1VJT7EyageYYo6iNQ/fdM+QVqLDY7oDK6iMhU9tD0pKsMIF1l +R9W9Utywcn9xxdvl4w4jSYt7l9Hy5Kw6hFv/Q0Px0Uj/OdU1gQhsKh5Ta3ncl7JxgZ/ Dbhg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:precedence:robot-unsubscribe:robot-id :message-id:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:references:in-reply-to:cc:subject:to:reply-to:sender :from:dkim-signature:dkim-signature:date; bh=JXVjcsJdNSBAy+AJdD8Wi18htPiGpdpHfDYRqypez2M=; fh=U/Hd0cPmVpmsXI9UC370Q88/l4pozXEkKxB1Pi0MTn0=; b=Jg96qWoxyM87ABcjasNL3YStL+8xnhsN3yzTINQ8kcKHsP0vh/MGHU1qus4hWM/byE r0TcOBP71wBpO92HdeqUtejN1azr1bWCcI7ZLC8HehMnj/mWI8z1ZpRZwPX7Oxzy45Eb qCnVxr1TaAiaVjWvoKW5cRRXXTr5PIPJs7nQgDRNHLmWxW3mjnhsML7UajaTe3p+Vmz6 bLmUzuekm925OS9r9tQQcEuC2bEBboibJrXCXPUQpDWqkxhtduUQQJpm/oTkygNIwxek LxtO+++lTazwX9hruPmTbjWfIZ3kBSEqrOCEmIl+32m3ng1eJZqhcSQQ5k9+D8B9mGot /EKw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=wixx07Ur; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-39099-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39099-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id o8-20020a170902bcc800b001d755b10444si7080323pls.463.2024.01.25.10.25.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jan 2024 10:25:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-39099-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=wixx07Ur; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-39099-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39099-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 70048299568 for ; Thu, 25 Jan 2024 18:25:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D8B2913475A; Thu, 25 Jan 2024 18:21:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="wixx07Ur"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="alYtOhTn" Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 905681350E4; Thu, 25 Jan 2024 18:21:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706206896; cv=none; b=O3Gdw4XV75swIf4NPtlXyrURhfE0wyY9H1N75wv5M/6TUuuMir6M4nHMtPqnsg14aJzY2dRx0t8mUP9aJxeDdKCtY0LilyWYPqoAemJYPkzbJ8ewcNeIuWK9KqW3YK4x3vTwFRC6u7dY44nj+KNSwlcaoVs7iXbMbM1OpYcux44= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706206896; c=relaxed/simple; bh=KHPb5CgivpgI79uEl585HOhoLg2EnMZ4JXgvvm96Vao=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=qREmDPcAc9vA4WaB82ZteEKhQBkiZNWhQbwSCRG57m4uvPI8L9i8UPimi21CY9J3+w/IAp9QlgI3VLkb3dqHXt55VDYjUlFdQsMxxes1uL5Ck1UEpFv2UuDfy/MPvTJejHcuaCgmLHhS0LEmozSgPW7f353zqPo+01rAhvR04P8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=wixx07Ur; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=alYtOhTn; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Date: Thu, 25 Jan 2024 18:21:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1706206884; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JXVjcsJdNSBAy+AJdD8Wi18htPiGpdpHfDYRqypez2M=; b=wixx07UrO4bqNWy7NuZN9nMorpoo0cIRghWad0K1BK+GdKA431QGI16QXavshXxgk7cBsA LUZJE2jcDb5nPMlBOvFLBSLX5HEkGom4tnEA/z+Ie0a/C8kOmrTOzFzvYd9ic4LOrhuiQ3 Kc9GXfworU7EbFTQ6opBpB0vnaS9pdAajkGQ7JaJVAg/XiHZuCg3BxCZWN+0CfNjR9pE9J QPkRU7tslwV5lvSczBNhxhIoMp/ooHx07xucFLwA3U/TnWFx2XY+Sldchk08F8qlNuJXPi 2FG9LmmOqwIFEmu2Qgw+SMzAGHMHfHmuy3niq1JR0edoOv1xpoKL6nE/3pVAxw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1706206884; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JXVjcsJdNSBAy+AJdD8Wi18htPiGpdpHfDYRqypez2M=; b=alYtOhTnGjAyxOxnfnNBmOcLbA9jR5UHS5UrHKJALrvNU5MXFlARPRvOVncrwyfQVJsrhM UAX74FwEHjdlHADQ== From: "tip-bot2 for H. Peter Anvin (Intel)" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/fred] x86/fred: Add a debug fault entry stub for FRED Cc: "H. Peter Anvin (Intel)" , Xin Li , Thomas Gleixner , Shan Kang , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231205105030.8698-24-xin3.li@intel.com> References: <20231205105030.8698-24-xin3.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <170620688384.398.17984833643981967432.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The following commit has been merged into the x86/fred branch of tip: Commit-ID: cae371b3f6ab203fda6faeb3de5a04481ebb85d3 Gitweb: https://git.kernel.org/tip/cae371b3f6ab203fda6faeb3de5a04481ebb85d3 Author: H. Peter Anvin (Intel) AuthorDate: Tue, 05 Dec 2023 02:50:12 -08:00 Committer: Thomas Gleixner CommitterDate: Thu, 25 Jan 2024 19:10:32 +01:00 x86/fred: Add a debug fault entry stub for FRED When occurred on different ring level, i.e., from user or kernel context, #DB needs to be handled on different stack: User #DB on current task stack, while kernel #DB on a dedicated stack. This is exactly how FRED event delivery invokes an exception handler: ring 3 event on level 0 stack, i.e., current task stack; ring 0 event on the #DB dedicated stack specified in the IA32_FRED_STKLVLS MSR. So unlike IDT, the FRED debug exception entry stub doesn't do stack switch. 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 in the format which debug_read_clear_dr6() returns for the IDT entry points. Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li Signed-off-by: Thomas Gleixner Tested-by: Shan Kang Link: https://lore.kernel.org/r/20231205105030.8698-24-xin3.li@intel.com --- arch/x86/kernel/traps.c | 43 +++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index c3b2f86..a03c233 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -51,6 +51,7 @@ #include #include #include +#include #include #include #include @@ -935,8 +936,7 @@ 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 noinstr void exc_debug_kernel(struct pt_regs *regs, unsigned long dr6) { /* * Disable breakpoints during exception handling; recursive exceptions @@ -948,6 +948,11 @@ static __always_inline void exc_debug_kernel(struct pt_regs *regs, * * Entry text is excluded for HW_BP_X and cpu_entry_area, which * includes the entry stack is excluded for everything. + * + * For FRED, nested #DB should just work fine. But when a watchpoint or + * breakpoint is set in the code path which is executed by #DB handler, + * it results in an endless recursion and stack overflow. Thus we stay + * with the IDT approach, i.e., save DR7 and disable #DB. */ unsigned long dr7 = local_db_save(); irqentry_state_t irq_state = irqentry_nmi_enter(regs); @@ -977,7 +982,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; /* @@ -1009,8 +1015,7 @@ out: local_db_restore(dr7); } -static __always_inline void exc_debug_user(struct pt_regs *regs, - unsigned long dr6) +static noinstr void exc_debug_user(struct pt_regs *regs, unsigned long dr6) { bool icebp; @@ -1094,6 +1099,34 @@ DEFINE_IDTENTRY_DEBUG_USER(exc_debug) { exc_debug_user(regs, debug_read_clear_dr6()); } + +#ifdef CONFIG_X86_FRED +/* + * When occurred on different ring level, i.e., from user or kernel + * context, #DB needs to be handled on different stack: User #DB on + * current task stack, while kernel #DB on a dedicated stack. + * + * This is exactly how FRED event delivery invokes an exception + * handler: ring 3 event on level 0 stack, i.e., current task stack; + * ring 0 event on the #DB dedicated stack specified in the + * IA32_FRED_STKLVLS MSR. So unlike IDT, the FRED debug exception + * entry stub doesn't do stack switch. + */ +DEFINE_FREDENTRY_DEBUG(exc_debug) +{ + /* + * FRED #DB stores DR6 on the stack in the format which + * debug_read_clear_dr6() returns for the IDT entry points. + */ + unsigned long dr6 = fred_event_data(regs); + + if (user_mode(regs)) + exc_debug_user(regs, dr6); + else + exc_debug_kernel(regs, dr6); +} +#endif /* CONFIG_X86_FRED */ + #else /* 32 bit does not have separate entry points. */ DEFINE_IDTENTRY_RAW(exc_debug)