From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 ED09233066A for ; Tue, 10 Feb 2026 07:28:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770708519; cv=none; b=bV0YbQX+R/3SQ3IU/qZB/+DzoWnJnx2FtQD9+QAhslu7FHozEwGelNOgN0KmvZ1hmdkwo+Z5a91eUEzYhBCXNiFMvQKs9QHHY+/Lsb6Rwvzm454yWpKINt2S24GdUf4xdUBluuCJz25AttmyV6AyiY1bhYXIeoZMB49YJ5kyA2o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770708519; c=relaxed/simple; bh=giY6QSrOhWk8g9pQ+Z7CI1wZdq6A9To47EZnqoRIlmQ=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=r8eqc+N4EgHgXR2+NaLTfiGaTmsq++/SvjMpFNf+1aq3EXdI2MHdaibgEOWcNvCIFsikv0weP6X8jjDZ6BFFfyd+cTGRxYIEWWTxRgUhEOsT+DK1dwUfEHxfJZZFMb21r7ODjRlbNOXHz4ahQgG/o+djEaaXWP9BROaYEHYIRMo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=gkJ901bH; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="gkJ901bH" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 61A7SBxa3220850 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 9 Feb 2026 23:28:12 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 61A7SBxa3220850 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026012301; t=1770708492; bh=pAYAZ2SYENYJTEpfVYgB79M3BM3x9oLywrGkuuJnmkU=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=gkJ901bHUrXsO9KjHnMctfOgc9bgndF4IsjLBo53eHArd28IXSMVipDY1JPpaxzDV v4ngqrrQSAHJP9BHI+1+pJAdYfyqPCZozSwz7EyX88TpngwBZJ/Jyn5LinMV6sFUBB IQM7RTayX8Z1f1Aq3qPt2n0DafNM2TD3JBHFa4DnnkQoMerWGYU32BOJgArvTR/zSy f4RteNACs1e3y480Ix+2tEswEMk0gI3QNKRdZgQX0rYo9PWZm3TSLPLuWrUci6fAas fTrD/H6GHVqjiJnzLQRbBoLkCTtwvlcMz5B2CN4LG3ciqqqIY6oRrleWNUXj1haSsr ayz/nu54Up/GQ== Date: Mon, 09 Feb 2026 23:28:06 -0800 From: "H. Peter Anvin" To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= , linux-kernel@vger.kernel.org, x86@kernel.org CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_0/4=5D_x86/mtrr=3A_Allow_MTR?= =?US-ASCII?Q?R_updates_on_multiple_CPUs_in_parallel?= User-Agent: K-9 Mail for Android In-Reply-To: <50f830e0-f69a-4f8c-a041-6ab6a8ee1cd8@suse.com> References: <20260130113625.599305-1-jgross@suse.com> <35527cf2-322f-410b-9942-5cba0956b237@suse.com> <50f830e0-f69a-4f8c-a041-6ab6a8ee1cd8@suse.com> Message-ID: <04FA5DE3-CD35-4D22-8300-8ADADF8E35C9@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On February 9, 2026 10:51:04 PM PST, "J=C3=BCrgen Gro=C3=9F" wrote: >On 09=2E02=2E26 19:37, H=2E Peter Anvin wrote: >> On February 9, 2026 1:12:59 AM PST, Juergen Gross w= rote: >>> Ping? >>>=20 >>> I'd really like to have this in 7=2E0, as it is fixing a real issue on >>> some machines =2E=2E=2E >>>=20 >>>=20 >>> Juergen >>>=20 >>> On 30=2E01=2E26 12:36, Juergen Gross wrote: >>>> Today MTRR updates are serialized to not happen on multiple CPUs at t= he >>>> same time, as the related coding is using global variables=2E >>>>=20 >>>> On huge machines with lots of CPUs this can result in problems, as su= ch >>>> updates are happening through stop_machine(), which will call the MTR= R >>>> update function with interrupts off on all CPUs at the same time=2E T= he >>>> interrupts will be switched on only after the last CPU has finished >>>> the MTRR update=2E As the update is required to run in uncached mode,= it >>>> can take easily several milliseconds on each CPU, resulting in the >>>> whole process to need several seconds=2E This in turn can cause the >>>> watchdog to trigger and to recognize a hard system lockup=2E >>>>=20 >>>> This series is changing the behavior by allowing the MTRR update to >>>> happen on all CPUs in parallel=2E >>>>=20 >>>> Changes in V2: >>>> - fix a function comment header in patch 2 >>>>=20 >>>> Juergen Gross (4): >>>> x86/mtrr: Move cache_enable() and cache_disable() to mtrr/generic= =2Ec >>>> x86/mtrr: Introduce MTRR work state structure >>>> x86/mtrr: Add a prepare_set hook to mtrr_ops >>>> x86/mtrr: Drop cache_disable_lock >>>>=20 >>>> arch/x86/include/asm/cacheinfo=2Eh | 2 - >>>> arch/x86/include/asm/mtrr=2Eh | 2 - >>>> arch/x86/kernel/cpu/cacheinfo=2Ec | 80 +---------------- >>>> arch/x86/kernel/cpu/mtrr/generic=2Ec | 139 +++++++++++++++++++++++= +----- >>>> arch/x86/kernel/cpu/mtrr/mtrr=2Ec | 3 + >>>> arch/x86/kernel/cpu/mtrr/mtrr=2Eh | 2 + >>>> 6 files changed, 122 insertions(+), 106 deletions(-) >>>>=20 >>>=20 >>=20 >> First of all, what machines are even needing MTRR updates these days? > >I'm not aware this machine really needed an update=2E > >> This isn't a rhetorical question=2E It is important to understand what = the underlying problem is=2E > >It just took several seconds for all CPUs to check if there is an update >needed=2E It might be an issue with firmware, topology, whatever=2E It ha= ppened >in a test doing 300 cold boots in a row after roughly 70 loop iterations, >always on one of the last CPUs=2E > >The issue shows that there IS a potential problem with doing the MTRR >update one CPU after the other, instead just doing it in parallel (which >is the "official" recommendation anyway)=2E See the comment in >cache_disable()=2E And it isn't as if the fix would be very complicated= =2E > > >Juergen You are assuming that it won't break any fragile systems=2E I'm much more = concerned about why this is happening at all=2E