Re: [PATCH v11 04/12] x86/mm: get INVLPGB count max from CPUID

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

On 2/19/25 09:52, Rik van Riel wrote:
>> CPU_SUP_AMD selects X86_BROADCAST_TLB_FLUSH which depends on
>> CPU_SUP_AMD which
>> selects X86_BROADCAST_TLB_FLUSH which depends on CPU_SUP_AMD...
>>
>> Why do you really need yet another Kconfig symbol? Just whack
>> X86_BROADCAST_TLB_FLUSH - it'll be enabled by default on everything
>> anyway.
> Dave specifically asked me to do things that way.

Yeah, I'm in camp "moar Kconfig!" and Boris is in camp "too many Kconfigs!".

I'm OK getting rid of the Kconfig as long as we have _some_ other way to
nicely identify the INVLPGB code (which I think the X86_FEATURE gives
us) _and_ that the overhead isn't too bad from leaving it compiled in
all the time.

The mmu_context is the one place that's kinda nasty without a Kconfig
option. I guess it's only a few bytes but it's a super silly waste of a
few bytes on i386, for example.

I also really like the _logical_ clarity that comes from something like:

+#ifdef CONFIG_X86_BROADCAST_TLB_FLUSH
+	u16 global_asid;
+	bool asid_transition;
+#endif

as opposed to:

+#ifdef CONFIG_64BIT
+ 	/* Only used with X86_FEATURE_INVLPGB */
+	u16 global_asid;
+	bool asid_transition;
+#endif

So, while I respect Boris's concern about Kconfig proliferation, I see
the user-invisible ones (the ones without a prompt) as pretty harmless.

Sorry for the maintainer crossfire, btw. I definitely don't want to be
thrashing you around too much.