From nobody Mon Dec 1 22:41:51 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 F1C272FFDDC; Wed, 26 Nov 2025 10:12:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764151942; cv=none; b=Fi9/l0Q1xUuZYPJuf/ZkQ0KLWmQKoYiSZsSRfGFEyk5HeZFS/X/2Y+whuYzvxb8TJKKoQVcXpuoj4uZfeQ0hZc9se4C0GtiCNYMjF+ZtWCnlrg3ztLhqODe/7yMUeYkFiSdZlU0C/bYQ/XRUKmGYbw1Vjrb+hSvbUsGwcUCQlXI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764151942; c=relaxed/simple; bh=aLKy8nSRP3ucBswNhLEEsXM7qghPXF05yi3+GN70UYM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jQR7l4B3E7IJ0aCw7MgVgo2xg4C4SDsRvnweHaNbGkqM3UTRi4l8AZuUx3il+8dfX0YrBO1PBkSh7dI9HTgv7fRkODoyU/1TXxNlvzWSk6nlSCO5pD8qirSsMx0J8HiN6vLhcCBstiOp1rJgqqt6XCL2ts8hKTCEYtxnbryc+cw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=j+xRCBUa; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="j+xRCBUa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764151940; x=1795687940; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aLKy8nSRP3ucBswNhLEEsXM7qghPXF05yi3+GN70UYM=; b=j+xRCBUasMEiPiku9z/cC+Ptuhw2vPCVaQaE1ZajNQtynYMiVDLNcnvJ R9HTW0ypruUqKHZ8k+O8ajOnlPwNkb1RP1o8NcLrJPKKDirpPjguR6hT/ b3ZRsU9K2enp4HcyVH94HMbeCuLeSUViLhEyESjzPc3lDMzigxrSy+mJo p8W1RjpJ18W4njhRSgg/Mp8usFosPKeXhW1zDgwPnkkvuTllAhvDo2eOq 50Ojrb1J481PSNieKDFqCusUw+Uf9kb/dwODUishTOMQ1jWkIw4IK1uen eT5BQAUwyAA7MaOxHsM1zIpvgcqlx6pFetMZ5FoYXooGr+aoIUq4bVB5B A==; X-CSE-ConnectionGUID: 0Gin3khaSLeW7lonLPEZpA== X-CSE-MsgGUID: O+mXjOS2Rgyou1R5xZMYEw== X-IronPort-AV: E=McAfee;i="6800,10657,11624"; a="70048227" X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="70048227" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2025 02:12:19 -0800 X-CSE-ConnectionGUID: hXYVgR9CSeyUbf0OzaEzOQ== X-CSE-MsgGUID: YqwaxlAtQWa5R7LYNu6GOA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="223623641" Received: from lxy-clx-4s.sh.intel.com ([10.239.48.22]) by orviesa002.jf.intel.com with ESMTP; 26 Nov 2025 02:12:16 -0800 From: Xiaoyao Li To: Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Kiryl Shutsemau Cc: x86@kernel.org, "H. Peter Anvin" , Rick Edgecombe , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Reinette Chatre , Chenyi Qiang , chao.p.peng@intel.com, xiaoyao.li@intel.com Subject: [PATCH 1/2] x86/split_lock: Don't try to handle user split lock in TDX guest Date: Wed, 26 Nov 2025 18:02:03 +0800 Message-ID: <20251126100205.1729391-2-xiaoyao.li@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251126100205.1729391-1-xiaoyao.li@intel.com> References: <20251126100205.1729391-1-xiaoyao.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When the host enables split lock detection feature, the split lock from guests (normal or TDX) triggers #AC. The #AC caused by split lock access within a normal guest triggers a VM Exit and is handled in the host. The #AC caused by split lock access within a TDX guest does not trigger a VM Exit and instead it's delivered to the guest self. The default "warning" mode of handling split lock depends on being able to temporarily disable detection to recover from the split lock event. But the MSR that disables detection is not accessible to a guest. This means that TDX guests today can not disable the feature or use the "warning" mode (which is the default). But, they can use the "fatal" mode. Force TDX guests to use the "fatal" mode. Signed-off-by: Xiaoyao Li --- arch/x86/kernel/cpu/bus_lock.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c index 981f8b1f0792..f278e4ea3dd4 100644 --- a/arch/x86/kernel/cpu/bus_lock.c +++ b/arch/x86/kernel/cpu/bus_lock.c @@ -315,9 +315,24 @@ void bus_lock_init(void) wrmsrq(MSR_IA32_DEBUGCTLMSR, val); } =20 +static bool split_lock_fatal(void) +{ + if (sld_state =3D=3D sld_fatal) + return true; + + /* + * TDX guests can not disable split lock detection. + * Force them into the fatal behavior. + */ + if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) + return true; + + return false; +} + bool handle_user_split_lock(struct pt_regs *regs, long error_code) { - if ((regs->flags & X86_EFLAGS_AC) || sld_state =3D=3D sld_fatal) + if ((regs->flags & X86_EFLAGS_AC) || split_lock_fatal()) return false; split_lock_warn(regs->ip); return true; --=20 2.43.0 From nobody Mon Dec 1 22:41:51 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 85B223016F6; Wed, 26 Nov 2025 10:12:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764151945; cv=none; b=bICtkifmGGKTFIb9rxyrFytOBnIwiKRh9X69A1TvLOXXFFAaVItPd342REelzSUZXZKjy/2eOTVdTAuq2ZMKavtqAZBwc8sobCKmT9U0nFPUgOqYtRyGbW1phzOBsnsRoPB8zOp/skqN+zI7t/UlT6CXjyZp9szopC9YI8X3W98= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764151945; c=relaxed/simple; bh=wYfnSJce/d68AkC3D5gkG5TdhGF5sx8GseHqKuyPJ3k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KG4TcPeD7wHxhMJp/zHzklF0XjvhYAbL4nGwxcNG1W3wHL2ZkkUXj3dNuj3NhMaxb79JxEDwOUAcEPo6TFOPAuwfqznkzBZXvHtTJgymaUIKsNeMh8JucXfWeHz68I9FSlmF122ufMHq5f6WAhcPNhcb7at8Lz5aRzo2RH/tkr4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TICKB7jl; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TICKB7jl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764151943; x=1795687943; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wYfnSJce/d68AkC3D5gkG5TdhGF5sx8GseHqKuyPJ3k=; b=TICKB7jl6Om1ByGYO7cfokx8AF1sA4bUNnPc0CH8bmZqBC9uUn73Ycpz qWtcLZ3LTryW3/dDD/UIWJGwCKkV1zDqpDH5WbNKRKmPepibz1Mv9zZBx /WrxHKl4MRuiRaCjLCqt4PcMp/lzl5qgDdyXi+W/cOeYXCpe3EpeM5vOh A4PLIvubktYqYdAzfLkxVSJN8yTq6OWuakZF9iP1NBrJiZyNahTpMAJob RH9sqXAjksNWLEBuv5OjFjLobRr3jaoT3o4JGzmoglak990f0RaspInyx akVQAOfa/llbh9OIMWCCz890XOTDMgSgat983wBGH2pY6P+8T4X8R+5OE w==; X-CSE-ConnectionGUID: cbJmFiSXSCCmop3iImraZQ== X-CSE-MsgGUID: p+kpR0FqRYWIEB8CEkMpgQ== X-IronPort-AV: E=McAfee;i="6800,10657,11624"; a="70048244" X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="70048244" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2025 02:12:23 -0800 X-CSE-ConnectionGUID: MinKU0NPQlaZPSL3+hTk9g== X-CSE-MsgGUID: xvoBGOAyThuJ90AHUjTW0A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="223623661" Received: from lxy-clx-4s.sh.intel.com ([10.239.48.22]) by orviesa002.jf.intel.com with ESMTP; 26 Nov 2025 02:12:20 -0800 From: Xiaoyao Li To: Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Kiryl Shutsemau Cc: x86@kernel.org, "H. Peter Anvin" , Rick Edgecombe , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Reinette Chatre , Chenyi Qiang , chao.p.peng@intel.com, xiaoyao.li@intel.com Subject: [PATCH 2/2] x86/split_lock: Describe #AC handling in TDX guest kernel log Date: Wed, 26 Nov 2025 18:02:04 +0800 Message-ID: <20251126100205.1729391-3-xiaoyao.li@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251126100205.1729391-1-xiaoyao.li@intel.com> References: <20251126100205.1729391-1-xiaoyao.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X86_FEATURE_HYPERVISOR and X86_FEATURE_BUS_LOCK_DETECT are always enumerated in a TDX guest because the corresponding CPUID values are fixed to 1 by the TDX module. Similar to a normal guest, a TDX guest never enumerates X86_FEATURE_SPLIT_LOCK_DETECT. When "split_lock_detect=3Doff", the TDX guest kernel log shows: x86/split lock detection: disabled and with other settings, it shows: x86/split lock detection: #DB: ... However, if the host enables split lock detection, a TDX guest receives #AC regardless of its own "split_lock_detect" configuration. The actual behavior does not match what the kernel log claims. Call out the possible #AC behavior on TDX and highlight that this behavior depends on the host's enabling of split lock detection. Signed-off-by: Xiaoyao Li --- arch/x86/kernel/cpu/bus_lock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c index f278e4ea3dd4..18695214d214 100644 --- a/arch/x86/kernel/cpu/bus_lock.c +++ b/arch/x86/kernel/cpu/bus_lock.c @@ -437,6 +437,9 @@ static void sld_state_show(void) pr_info("#DB: setting system wide bus lock rate limit to %u/sec\n", bld= _ratelimit.burst); break; } + + if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) + pr_info("tdx: #AC depends on host configuration: crashing the kernel on = kernel split_locks and sending SIGBUS on user-space split_locks\n"); } =20 void __init sld_setup(struct cpuinfo_x86 *c) --=20 2.43.0