From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 E6FDD26ED5F for ; Wed, 26 Nov 2025 12:17:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764159449; cv=none; b=rbpGbuF+MS5zuHuX0k+f7dHi6PUaXDNBvjl3UzHxD/5r2o0hcDVTRv8A9eLDni3F8qrs1CrLYDG9dHIFGfP3Aa3tnZ0Uhx+0cqCMUoHvmvspdC3hyMWIWsFJeQBCa0OGKKAZoNKwHi61OpUBfq3rhg00daAWqQHRU0d1f/dcJt4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764159449; c=relaxed/simple; bh=Zi8Z/1JVVN5yj9xGlROnJ3igsOEtV3FzNhPX+qSZd4o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LKv91cRc3SKBhdwOcwrOYsTBZxIBWCr2layJLxGUfLxoyBoE5s5jn6mlhlNxuJBXNPPuFN75vtCKo6DLJGAJHHvELkRvGR4iGagmwWrWb+VvDsKjCAqGUUnTGGXlL9qjo9GcqigU3XQKurmi7+5u6ncHLX1g1qITUZJoUYVWxVs= 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=QjDJL9h1; arc=none smtp.client-ip=192.198.163.13 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="QjDJL9h1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764159448; x=1795695448; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Zi8Z/1JVVN5yj9xGlROnJ3igsOEtV3FzNhPX+qSZd4o=; b=QjDJL9h11SL3aeBI8Bgf3HEB+HRtqrauPGIUw2kPNU7/fw7vmHTO3Y4a U1oa9RoadR9HWhkPhRuLjkczvprR8FjIMld7YCBXj8Axx+LzIKQI/JutH +PFmJqBbkxTXewSrGbv8gaYORXnAbeKnJbxQGNwLR0W57CwWst/2n/AGF 18y581Nlw6myZMlT8jSnNNegPAkaJ2mT6XHIGr6gY4ZRtvtPZaC5edsDs 2i3TTkUcf/Aj2couL5BU1NqCS5vMDakgAcRA6A8UpqgWyc47dRDroVol7 Plz4PQUBue+U4fdYLVqTDIlXcaG5Iq1cmiHmp9ZWZCkai9tVKtVMcvU9p g==; X-CSE-ConnectionGUID: /wehd9/kSSSTLT8EBuST9w== X-CSE-MsgGUID: kp/l0DwmSVOlBtYmydQH7g== X-IronPort-AV: E=McAfee;i="6800,10657,11624"; a="68784257" X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="68784257" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2025 04:17:27 -0800 X-CSE-ConnectionGUID: 3xsZio4cQQarbrm46XbJVw== X-CSE-MsgGUID: zraMlUiYRnS/P7RYYBLi6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="192944295" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.240.173]) ([10.124.240.173]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2025 04:17:23 -0800 Message-ID: <33fe9716-ef3b-42f3-9806-4bd23fed6949@intel.com> Date: Wed, 26 Nov 2025 20:17:18 +0800 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/split_lock: Don't try to handle user split lock in TDX guest To: Kiryl Shutsemau Cc: Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , 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 References: <20251126100205.1729391-1-xiaoyao.li@intel.com> <20251126100205.1729391-2-xiaoyao.li@intel.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/26/2025 7:25 PM, Kiryl Shutsemau wrote: > On Wed, Nov 26, 2025 at 06:02:03PM +0800, Xiaoyao Li wrote: >> 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); >> } >> >> +static bool split_lock_fatal(void) >> +{ >> + if (sld_state == 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 == sld_fatal) >> + if ((regs->flags & X86_EFLAGS_AC) || split_lock_fatal()) >> return false; > > Maybe it would be cleaner to make it conditional on > cpu_model_supports_sld instead of special-casing TDX guest? > > #AC on any platfrom when we didn't asked for it suppose to be fatal, no? But TDX is the only one has such special non-architectural behavior. For example, for normal VMs under KVM, the behavior is x86 architectural. MSR_TEST_CTRL is not accessible to normal VMs, and no split lock #AC will be delivered to the normal VMs because it's handled by KVM. >> split_lock_warn(regs->ip); >> return true; >> -- >> 2.43.0 >> >