On 18.11.2025 20:42, Andrew Cooper wrote: > On 18/11/2025 3:08 pm, Jan Beulich wrote: >> There's no need to invoke CPUID yet another time. However, as the host CPU >> policy is set up only shortly after init_intel() ran on the BSP, defer the >> logic to a pre-SMP initcall. This can't be (a new) one in cpu/intel.c >> though, as that's linked after acpi/cpu_idle.c (which is where we already >> need the feature set). Since opt_arat is local to the cpu/ subtree, >> introduce a new Intel-specific helper to hold the code needed. >> >> Further, as we assume symmetry anyway, use setup_force_cpu_cap() and hence >> limit the checking to the boot CPU. >> >> Signed-off-by: Jan Beulich <[email protected]> >> --- >> The need to move where cpu_has_arat is checked would go away if we did >> away with opt_arat (as mentioned in the previous patch), and hence could >> use cpu_has_arat directly where right now XEN_ARAT is checked. >> >> --- a/xen/arch/x86/acpi/cpu_idle.c >> +++ b/xen/arch/x86/acpi/cpu_idle.c >> @@ -1666,6 +1666,9 @@ static int __init cf_check cpuidle_presm >> { >> void *cpu = (void *)(long)smp_processor_id(); >> >> + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) >> + intel_init_arat(); > > I really would prefer to avoid the need for this.
So would I, but ... > Now that microcode loading has moved to the start of day, we can drop > most of the order-of-init complexity for CPUID/etc, and I expect that > problems like this will cease to exist as a result. > > Notably, we've now got no relevant difference between early_init() and > regular init(). That was a complexity we inherited from Linux. ... I don't see how this leads to any concrete suggestion as to better arrangements. With cpu_has_arat using the host policy now, setup_force_cpu_cap(X86_FEATURE_XEN_ARAT) being conditional upon that has to run _after_ calculate_host_policy(), which in turn runs after intel_init(). We could add a .c_late_init hook to struct cpu_dev, but doing so felt like overkill for the purpose here. Plus it feels like that wouldn't really address your concern either. Jan
