Re: [PATCH 2/3] x86/mm: Fix early boot use of INVPLGB

[Dave Hansen <dave.hansen@intel.com>]

On 6/2/25 06:30, Rik van Riel wrote:
> Use of the INVLPGB instruction is done based off the X86_FEATURE_INVLPGB
> CPU feature, which is provided directly by the hardware.
> 
> If invlpgb_kernel_range_flush is called before the kernel has read
> the value of invlpgb_count_max from the hardware, the normally
> bounded loop can become an infinite loop if invlpgb_count_max is
> initialized to zero.
> 
> Fix that issue by initializing invlpgb_count_max to 1.
> 
> This way INVPLGB at early boot time will be a little bit slower
> than normal (with initialized invplgb_count_max), and not an
> instant hang at bootup time.

The INVLPGB instruction has limits on how many invalidations it can
perform at once. That limit is enumerated in CPUID, read by the kernel,
and stored in 'invlpgb_count_max'. Ranged invalidation (like
invlpgb_kernel_range_flush()) break up their invalidations so that they
do not exceed the limit.

However, early boot code currently attempts to do ranged invalidations
before populating 'invlpgb_count_max'. There's a for() loop which is
basically:

	for (...; addr < end; addr += invlpgb_count_max*PAGE_SIZE)

It doesn't make much progress when invlpgb_count_max==0.

... then the rest

---

BTW, how was this code even _working_ without this patch? Are the early
boot ranged invalidations infrequent or something?

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>