Message ID | 20240124130650.496056-1-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-37049-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp1129322dyi; Wed, 24 Jan 2024 09:10:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IF/PHnCgx7y13Oxuj1WlMXectuhpP/MX0HyAaQJtnD7fOw+9JU+Lebl+h+clb5U83IDj673 X-Received: by 2002:a05:6a00:3cc3:b0:6db:c6b3:2470 with SMTP id ln3-20020a056a003cc300b006dbc6b32470mr10374353pfb.3.1706116227730; Wed, 24 Jan 2024 09:10:27 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706116227; cv=pass; d=google.com; s=arc-20160816; b=iTjqmupZNB8sGdXei6qkf7sDqmcEWuwcMtaFcNQFv76nLb4GCI3wXa8/6mUZLqxYRD UW025fyJq6tk8isFr9LF0EJgwiDzJzTQHPeumZGh9t/JYYALxopi8xKldKKM3K0uwl5p T9aQVTrWE3oWXjjyG/pUBz/RcTxgyDDbObfsmYcPbb6EIxpym4t75mQSUg+WZkU9zIZt I4MINGP4PRjeR7zmb2rsUdZ7MKxY+m8j6ZqDm61x/Oo64dVAz3d/4s4MawqO7ewWCuNR x1Wz5RfxR+QcI4IetzSoxk/Sblcx6xw4Pfq7c6Oq/+3P6ArUHlSZYbVhk4TT3wY9CpE9 gQ3A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=MpWg2Uv8rXmrnca2RCkN8JwCYhgneY9t1BFcGhdTIlg=; fh=e5OOrCjmc87s/YZszbOQCKg9A11Jj7/axfrwJ2Itr5A=; b=QezLvITpkqRXaQBf7OguWF+lC7R3qk7rpnt+LkKriYB2+yhGqKmia1LZw4s0w0on9v Ga8yRH4ez3OTmCfjOokm6y2DrO/X8Sf4zHNEq2AnaMLceblU85ld4rIPcpeIiMAOyM2y PxvOOpubyjxNi9JI5WLgIZav0V/wXQUeD3kBY283I+DT42fvZCjAE5qQrqWos+6S2RSN yeiDqtqI6/1Wd8PkleypQC1YwMI84/59n8PjQZC/t0f6p4UmJoA51bv7bERvv6jJB1pU iA52Thp7/OxHOLUB+bl0Iz/qernAK75q5F888p0pYi2NwG3QnQzP5gd1fJ87PU3oglVP TCxg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=A05A0igJ; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-37049-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37049-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id a41-20020a056a001d2900b006dbd7f1a189si6880158pfx.334.2024.01.24.09.10.27 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 09:10:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-37049-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=A05A0igJ; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-37049-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37049-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com 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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 1AAF3B2CF41 for <ouuuleilei@gmail.com>; Wed, 24 Jan 2024 13:07:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5B2A877F0E; Wed, 24 Jan 2024 13:07:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="A05A0igJ" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (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 7FD357765E for <linux-kernel@vger.kernel.org>; Wed, 24 Jan 2024 13:06:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706101617; cv=none; b=EITvvkoD2irmoVlsYcwGEM5dLUMRjR203UwdYXFUth7DtuwWPFzVuoOVz+V+u4VM+9sltJc+DSIYPgzmoOuS1oOHwxZdWXg3nwvYQyX3bXqzSlNG01bqRWesEG4C54mUDGuU5i9eROplsn7hsif27Eh8jPOZZn1DO+oYgP8PXnA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706101617; c=relaxed/simple; bh=dujYRm0zmFA26MfiC8o/r8uHHYPjm22iKpWqpqVW4s4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=nTeM8QyRwDn/EDhf+UlwEtHFVIAo14R4RHu7i8UWXzBjZkpqxoTuvjFv33YGXt7lFFvaEVnL/UByQqU8xgc5oqpTcKOTfrGMLv9haXh+Qej+u5GEE5SpjPRib5pfpuCWTbrMCMcFPhyGw3Vaq2C0I44bg/DN+Dz1ytKBtaYqF9E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=A05A0igJ; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706101617; x=1737637617; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=dujYRm0zmFA26MfiC8o/r8uHHYPjm22iKpWqpqVW4s4=; b=A05A0igJYy5Ev2rG+NRD2rZRcipT4HegVmHZLqHw5XywOMozcCr4zPY0 RZh8oEy210/5qOVE5z/ZD2mPCa06KrUoThCgrpDLgvI6pWQHj4EwDTkDb 4a0DN8AtFGEErBat+aDQ//rbDqVJA9M4iJ/h148mnc+0XPQU7ABSh7scx yOgU8K/xv9eYM6ZJ+RdZT3ntYdgIMowc62nLoZF2dJ77PhyGlzcaYPbuN Lr++s5YBII3/rxKhpP6FUyc82oA+lVypbQ31yqjL++ULc8oZTWSOrt5gG I2oSFUeIJ/tKELaK9hrSSTvTB3/ZgIOLU3hG9x4HOUPBglKOchFJH6Q5R w==; X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="1727545" X-IronPort-AV: E=Sophos;i="6.05,216,1701158400"; d="scan'208";a="1727545" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2024 05:06:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="905590853" X-IronPort-AV: E=Sophos;i="6.05,216,1701158400"; d="scan'208";a="905590853" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 24 Jan 2024 05:06:53 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id 1675B5E8; Wed, 24 Jan 2024 15:06:51 +0200 (EET) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: Isaku Yamahata <isaku.yamahata@intel.com>, x86@kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Juergen Gross <jgross@suse.com> Subject: [PATCH, RESEND] x86/pat: Simplifying the PAT programming protocol Date: Wed, 24 Jan 2024 15:06:50 +0200 Message-ID: <20240124130650.496056-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788992529716503754 X-GMAIL-MSGID: 1788992529716503754 |
Series |
[RESEND] x86/pat: Simplifying the PAT programming protocol
|
|
Commit Message
Kirill A. Shutemov
Jan. 24, 2024, 1:06 p.m. UTC
The programming protocol for the PAT MSR follows the MTRR programming protocol. However, this protocol is cumbersome and requires disabling caching (CR0.CD=1), which is not possible on some platforms. Specifically, a TDX guest is not allowed to set CR0.CD. It triggers a #VE exception. Turned out the requirement to follow the MTRR programming protocol for PAT programming is unnecessarily strict. The new Intel Software Developer Manual[1] (December 2023) relaxes this requirement. Please refer to the section titled "Programming the PAT" for more information. The AMD documentation does not link PAT programming to MTRR. The kernel only needs to flush the TLB after updating the PAT MSR. The set_memory code already takes care of flushing the TLB and cache when changing the memory type of a page. [1] http://www.intel.com/sdm Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Juergen Gross <jgross@suse.com> --- arch/x86/kernel/cpu/cacheinfo.c | 7 ++++--- arch/x86/mm/pat/memtype.c | 9 +++------ 2 files changed, 7 insertions(+), 9 deletions(-)
Comments
On Wed, Jan 24, 2024 at 03:06:50PM +0200, Kirill A. Shutemov wrote: > The programming protocol for the PAT MSR follows the MTRR programming > protocol. However, this protocol is cumbersome and requires disabling > caching (CR0.CD=1), which is not possible on some platforms. > > Specifically, a TDX guest is not allowed to set CR0.CD. It triggers > a #VE exception. > > Turned out the requirement to follow the MTRR programming protocol for > PAT programming is unnecessarily strict. The new Intel Software > Developer Manual[1] (December 2023) relaxes this requirement. Please > refer to the section titled "Programming the PAT" for more information. > > The AMD documentation does not link PAT programming to MTRR. > > The kernel only needs to flush the TLB after updating the PAT MSR. The > set_memory code already takes care of flushing the TLB and cache when > changing the memory type of a page. > > [1] http://www.intel.com/sdm > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Reviewed-by: Juergen Gross <jgross@suse.com> Any feedback?
On Wed, Jan 24, 2024 at 03:06:50PM +0200, Kirill A. Shutemov wrote: > The programming protocol for the PAT MSR follows the MTRR programming > protocol. However, this protocol is cumbersome and requires disabling > caching (CR0.CD=1), which is not possible on some platforms. > > Specifically, a TDX guest is not allowed to set CR0.CD. It triggers > a #VE exception. > > Turned out the requirement to follow the MTRR programming protocol for > PAT programming is unnecessarily strict. The new Intel Software > Developer Manual[1] (December 2023) relaxes this requirement. Please > refer to the section titled "Programming the PAT" for more information. How about you state that requirement here instead of referring to that doc which is hard to read and changes constantly? I'd prefer to have that programming requirement spelled out here to know in the future what that requirement was and what "variant" was added to the kernel in case someone decides to relax it even more. > > The AMD documentation does not link PAT programming to MTRR. > > The kernel only needs to flush the TLB after updating the PAT MSR. The > set_memory code already takes care of flushing the TLB and cache when > changing the memory type of a page. So far so good. However, what guarantees that this relaxing of the protocol doesn't break any existing machines? If anything, this patch needs to be tested on everything possible. I can do that on AMD hw and some old Intels, just to be sure. > @@ -296,13 +298,8 @@ void __init pat_bp_init(void) > /* > * Xen PV doesn't allow to set PAT MSR, but all cache modes are > * supported. > - * When running as TDX guest setting the PAT MSR won't work either > - * due to the requirement to set CR0.CD when doing so. Rely on > - * firmware to have set the PAT MSR correctly. > */ > - if (pat_disabled || > - cpu_feature_enabled(X86_FEATURE_XENPV) || > - cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) { > + if (pat_disabled || cpu_feature_enabled(X86_FEATURE_XENPV)) { > init_cache_modes(pat_msr_val); > return; What does that mean, now, practically? That TDX guests virtualize the PAT MSR just like with any other guest or what is going on there? This should be explicitly stated in the commit message. Thx.
On Wed, Jan 31, 2024 at 06:57:38PM +0100, Borislav Petkov wrote: > On Wed, Jan 24, 2024 at 03:06:50PM +0200, Kirill A. Shutemov wrote: > > The programming protocol for the PAT MSR follows the MTRR programming > > protocol. However, this protocol is cumbersome and requires disabling > > caching (CR0.CD=1), which is not possible on some platforms. > > > > Specifically, a TDX guest is not allowed to set CR0.CD. It triggers > > a #VE exception. > > > > Turned out the requirement to follow the MTRR programming protocol for > > PAT programming is unnecessarily strict. The new Intel Software > > Developer Manual[1] (December 2023) relaxes this requirement. Please > > refer to the section titled "Programming the PAT" for more information. > > How about you state that requirement here instead of referring to that > doc which is hard to read and changes constantly? > > I'd prefer to have that programming requirement spelled out here to know > in the future what that requirement was and what "variant" was added to > the kernel in case someone decides to relax it even more. I summarized the requirements below: TLB has to flashed. Here's what SDM says: The operating system (OS) is responsible for ensuring that changes to a PAT entry occur in a manner that maintains the consistency of the processor caches and translation lookaside buffers (TLB). It requires the OS to invalidate all affected TLB entries (including global entries) and all entries in all paging-structure caches. It may also require flushing of the processor caches in certain situations. ... Example of a sequence to invalidate the processor TLBs and caches (if necessary): 1. If the PCIDE or PGE flag is set in CR4, flush TLBs by clearing one of those flags (then restore the flag via a subsequent CR4 write). Otherwise, flush TLBs by executing a MOV from control register CR3 to another register and then a MOV from that register back to CR3. 2. In the case that there are changes to memory-type mappings for which cache self-snooping behavior would be problematic given the existing mappings (e.g., changing a cache line's memory type from WB to UC to be used for memory-mapped I/O), then cache flushing is also required. This can be done by executing CLFLUSH operations for all affected cache lines or by executing the WBINVD instruction (recommended only if there are a large number of affected mappings or if it is unknown which mappings are affected) The second step is relevant for set_memory code that already does the flushing on changing memory type. > > The AMD documentation does not link PAT programming to MTRR. > > > > The kernel only needs to flush the TLB after updating the PAT MSR. The > > set_memory code already takes care of flushing the TLB and cache when > > changing the memory type of a page. > > So far so good. However, what guarantees that this relaxing of the > protocol doesn't break any existing machines? Our HW folks confirmed that the new optimized sequence works on all past processors that support PAT. > If anything, this patch needs to be tested on everything possible. I can > do that on AMD hw and some old Intels, just to be sure. Testing wouldn't hurt, but it cannot possibly prove that the new flow is safe by testing. > > @@ -296,13 +298,8 @@ void __init pat_bp_init(void) > > /* > > * Xen PV doesn't allow to set PAT MSR, but all cache modes are > > * supported. > > - * When running as TDX guest setting the PAT MSR won't work either > > - * due to the requirement to set CR0.CD when doing so. Rely on > > - * firmware to have set the PAT MSR correctly. > > */ > > - if (pat_disabled || > > - cpu_feature_enabled(X86_FEATURE_XENPV) || > > - cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) { > > + if (pat_disabled || cpu_feature_enabled(X86_FEATURE_XENPV)) { > > init_cache_modes(pat_msr_val); > > return; > > What does that mean, now, practically? > > That TDX guests virtualize the PAT MSR just like with any other guest or > what is going on there? > > This should be explicitly stated in the commit message. PAT MST was always virtualized, but we was not able to program it as we followed MTRR protocol that sets CR0.CD. And I covered it in the commit message: Specifically, a TDX guest is not allowed to set CR0.CD. It triggers a #VE exception.
On Wed, Jan 31, 2024 at 08:52:46PM +0200, Kirill A. Shutemov wrote: > The second step is relevant for set_memory code that already does the > flushing on changing memory type. So the "relaxation" is the removal of that CR0.CD requirement? > Our HW folks confirmed that the new optimized sequence works on all past > processors that support PAT. Your folks confirmed that for all released hw and for x86 hardware from other vendors? > Testing wouldn't hurt, but it cannot possibly prove that the new flow is > safe by testing. This basically says that I should not take this patch at all as there's no way of even testing it?! I hope I'm misunderstanding you. > PAT MST was always virtualized, but we was not able to program it as we > followed MTRR protocol that sets CR0.CD. And I covered it in the commit > message: > > Specifically, a TDX guest is not allowed to set CR0.CD. It triggers > a #VE exception. Ok, I'll extend that part once the rest has been sorted out. Thx.
On Wed, Jan 31, 2024 at 09:23:40PM +0100, Borislav Petkov wrote: > On Wed, Jan 31, 2024 at 08:52:46PM +0200, Kirill A. Shutemov wrote: > > The second step is relevant for set_memory code that already does the > > flushing on changing memory type. > > So the "relaxation" is the removal of that CR0.CD requirement? And double WBINVD if the machine has no X86_FEATURE_SELFSNOOP (before and after TLB flush). > > Our HW folks confirmed that the new optimized sequence works on all past > > processors that support PAT. > > Your folks confirmed that for all released hw and for x86 hardware from > other vendors? No. They can only talk for Intel CPUs. But AMD docs don't require MTTR flow to begin with. It is better to double-check on AMD side. > > Testing wouldn't hurt, but it cannot possibly prove that the new flow is > > safe by testing. > > This basically says that I should not take this patch at all as there's > no way of even testing it?! > > I hope I'm misunderstanding you. Testing can prove that the proposed patch is broken if a problem show ups. But if you found no issue during testing you cannot say that the patch is safe. You could just get lucky and don't hit pathological scenario with broken cache/TLB aliases or something. It is better to get confirmation from HW folks.
On Thu, Feb 01, 2024 at 12:17:32AM +0200, Kirill A. Shutemov wrote:
> It is better to get confirmation from HW folks.
Yah, lemme see what I can do.
On Thu, Feb 01, 2024 at 12:17:32AM +0200, Kirill A. Shutemov wrote: > > So the "relaxation" is the removal of that CR0.CD requirement? So I'm looking at the SDM, revisions 081US and 082US. Section "12.11.8 MTRR Considerations in MP Systems" still has "4. Enter the no-fill cache mode. (Set the CD flag in control register CR0 to 1 and the NW flag to 0.)" and "4. Enter the no-fill cache mode. (Set the CD flag in control register CR0 to 1 and the NW flag to 0.)" so where is that relaxation written? Am I looking at the wrong place? > And double WBINVD if the machine has no X86_FEATURE_SELFSNOOP (before and > after TLB flush). That's still there too. Steps 5 and 11, respectively. Hmmm?
On Tue, Feb 13, 2024 at 05:15:14PM +0100, Borislav Petkov wrote: > On Thu, Feb 01, 2024 at 12:17:32AM +0200, Kirill A. Shutemov wrote: > > > So the "relaxation" is the removal of that CR0.CD requirement? > > So I'm looking at the SDM, revisions 081US and 082US. > > Section > > "12.11.8 MTRR Considerations in MP Systems" The point is that PAT programming doesn't need to follow MTRR considerations anymore. Previously "Programming the PAT" section had this: The operating system is responsible for ensuring that changes to a PAT entry occur in a manner that maintains the consistency of the processor caches and translation lookaside buffers (TLB). This is accomplished by following the procedure as specified in Section 12.11.8, “MTRR Considerations in MP Systems,” for changing the value of an MTRR in a multiple processor system. It requires a specific sequence of operations that includes flushing the processors caches and TLBs. The new version points to MTTR consideration as one of possible way to invalidate TLB and caches: The operating system (OS) is responsible for ensuring that changes to a PAT entry occur in a manner that maintains the consistency of the processor caches and translation lookaside buffers (TLB). It requires the OS to invalidate all affected TLB entries (including global entries) and all entries in all paging-structure caches. It may also require flushing of the processor caches in certain situations. This can be accomplished in various ways, including the sequence below or by following the procedure specified in Section 12.11.8, “MTRR Considerations in MP Systems.” (See Section 4.10.4, “Invalidation of TLBs and Paging-Structure Caches” for additional background information.) Also note that in a multi-processor environment, it is the software's responsibility to resolve differences in conflicting memory types across logical processors that may arise from changes to the PAT (e.g., if two logical processors map a linear address to the same physical address but have PATs that specify a different memory type for that physical address). The new text follows with example of sequence that flushes TLB and caches. And it doesn't touch CR0.CD.
On Tue, Feb 13, 2024 at 06:57:19PM +0200, Kirill A. Shutemov wrote: > The new text follows with example of sequence that flushes TLB and > caches. And it doesn't touch CR0.CD. Ok, sounds like AMD is fine here. I'm going to take this one and see what explodes. If something does, we can always remove it. Thx.
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c index c131c412db89..78afad50a7c0 100644 --- a/arch/x86/kernel/cpu/cacheinfo.c +++ b/arch/x86/kernel/cpu/cacheinfo.c @@ -1118,15 +1118,16 @@ static void cache_cpu_init(void) unsigned long flags; local_irq_save(flags); - cache_disable(); - if (memory_caching_control & CACHE_MTRR) + if (memory_caching_control & CACHE_MTRR) { + cache_disable(); mtrr_generic_set_state(); + cache_enable(); + } if (memory_caching_control & CACHE_PAT) pat_cpu_init(); - cache_enable(); local_irq_restore(flags); } diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c index 0904d7e8e126..0d72183b5dd0 100644 --- a/arch/x86/mm/pat/memtype.c +++ b/arch/x86/mm/pat/memtype.c @@ -240,6 +240,8 @@ void pat_cpu_init(void) } wrmsrl(MSR_IA32_CR_PAT, pat_msr_val); + + __flush_tlb_all(); } /** @@ -296,13 +298,8 @@ void __init pat_bp_init(void) /* * Xen PV doesn't allow to set PAT MSR, but all cache modes are * supported. - * When running as TDX guest setting the PAT MSR won't work either - * due to the requirement to set CR0.CD when doing so. Rely on - * firmware to have set the PAT MSR correctly. */ - if (pat_disabled || - cpu_feature_enabled(X86_FEATURE_XENPV) || - cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) { + if (pat_disabled || cpu_feature_enabled(X86_FEATURE_XENPV)) { init_cache_modes(pat_msr_val); return; }