[PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds

[PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds

[Alejandro Vallejo]

Debug builds traditionally ship with a 10-bit counter for the TLB
clock. This forces global TLB shootdowns with high frequency, making
debug builds unsuitable for any form of real time testing.

Remove this quirk, unifying release and debug under a wide counter.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
v1: https://lore.kernel.org/xen-devel/20260112140851.55590-1-alejandro.garciavallejo@amd.com/
v2:
  * Remove WRAP_MASK instead.
  * Commit message/title rewrites.
---
 xen/arch/x86/flushtlb.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 09e676c151..23721bb52c 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -19,13 +19,6 @@
 #include <asm/pv/domain.h>
 #include <asm/spec_ctrl.h>
 
-/* Debug builds: Wrap frequently to stress-test the wrap logic. */
-#ifdef NDEBUG
-#define WRAP_MASK (0xFFFFFFFFU)
-#else
-#define WRAP_MASK (0x000003FFU)
-#endif
-
 #ifndef CONFIG_PV
 # undef X86_CR4_PCIDE
 # define X86_CR4_PCIDE 0
@@ -55,7 +48,7 @@ static u32 pre_flush(void)
         /* Clock wrapped: someone else is leading a global TLB shootdown. */
         if ( unlikely(t1 == 0) )
             goto skip_clocktick;
-        t2 = (t + 1) & WRAP_MASK;
+        t2 = t + 1;
     }
     while ( unlikely((t = cmpxchg(&tlbflush_clock, t1, t2)) != t1) );
 

base-commit: a2a34d76643e49ccc949296c9a45888034e50b55
-- 
2.43.0

Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds

[Andrew Cooper]

On 13/01/2026 12:09 pm, Alejandro Vallejo wrote:
> Debug builds traditionally ship with a 10-bit counter for the TLB
> clock. This forces global TLB shootdowns with high frequency, making
> debug builds unsuitable for any form of real time testing.
>
> Remove this quirk, unifying release and debug under a wide counter.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds

[Roger Pau Monné]

On Tue, Jan 13, 2026 at 01:09:58PM +0100, Alejandro Vallejo wrote:
> Debug builds traditionally ship with a 10-bit counter for the TLB
> clock. This forces global TLB shootdowns with high frequency, making
> debug builds unsuitable for any form of real time testing.
> 
> Remove this quirk, unifying release and debug under a wide counter.

I wonder if it makes any sense to provide this as a Kconfig tunable,
set to 32bit width for both debug and release builds?

Not sure whether there's a ton of interest in stressing the flushing
however, and by then it's a small hack to adjust the code itself.

Regards, Roger.

Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds

[Andrew Cooper]

On 13/01/2026 2:17 pm, Roger Pau Monné wrote:
> On Tue, Jan 13, 2026 at 01:09:58PM +0100, Alejandro Vallejo wrote:
>> Debug builds traditionally ship with a 10-bit counter for the TLB
>> clock. This forces global TLB shootdowns with high frequency, making
>> debug builds unsuitable for any form of real time testing.
>>
>> Remove this quirk, unifying release and debug under a wide counter.
> I wonder if it makes any sense to provide this as a Kconfig tunable,
> set to 32bit width for both debug and release builds?

That was v1, and both Jan and myself said "prefer not".

~Andrew

Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds

[Roger Pau Monné]

On Tue, Jan 13, 2026 at 02:18:22PM +0000, Andrew Cooper wrote:
> On 13/01/2026 2:17 pm, Roger Pau Monné wrote:
> > On Tue, Jan 13, 2026 at 01:09:58PM +0100, Alejandro Vallejo wrote:
> >> Debug builds traditionally ship with a 10-bit counter for the TLB
> >> clock. This forces global TLB shootdowns with high frequency, making
> >> debug builds unsuitable for any form of real time testing.
> >>
> >> Remove this quirk, unifying release and debug under a wide counter.
> > I wonder if it makes any sense to provide this as a Kconfig tunable,
> > set to 32bit width for both debug and release builds?
> 
> That was v1, and both Jan and myself said "prefer not".

We already have this fixed to 32-bit width in XenServer patch queue for
both release and debug builds.  Certainly no strong opinion, I never
had the need to tweak this, and anyone that has to will likely be
perfectly fine with adjusting the code.

Thanks, Roger.