On 7/31/25 21:43, Sohil Mehta wrote:
...
> Could deferring enforcement lead to a scenario where we end up with
> different CR4 values on different CPUs? Maybe I am misinterpreting this
> and protecting against in-kernel errors is not a goal.
Sure, theoretically.
But if that's a concern, it can be checked at the time that enforcement
starts:
for_each_online_cpu(cpu) {
unsigned long cr4 = per_cpu(cpu_tlbstate.cr4, cpu);
if ((cr4 & cr4_pinned_mask) == cr4_pinned_bits))
continue;
WARN("blah blah");
}
Or use smp_call_function() to check each CPU's CR4 directly.
Or, the next time that CPU does a TLB flush that toggles X86_CR4_PGE,
it'll get the warning from the regular pinning path.
So, sure, this does widen the window during boot where a secondary CPU
might get a bad CR4 value, and it would make it harder to track down
where it happened. We _could_ print a pr_debug() message when the bit
gets cleared but not enforce things if anyone is super worried about this.
> In general, you want to delay the CR pinning enforcement until
> absolutely needed. I am curious about the motivation. I understand we
> should avoid doing it at arbitrary points in the boot. But,
> arch_cpu_finalize_init() and early_initcall() seem to be decent
> mileposts to me.
>
> Are you anticipating that we would need to move setup_cr_pinning() again
> when another user similar to EFI shows up?
Yep.
