Re: [PATCH 6/8] x86/Intel: use host CPU policy for ARAT checking

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 <jbeulich@xxxxxxxx>
> ---
> 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.

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.

~Andrew