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

[Jan Beulich <jbeulich@xxxxxxxx>]

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 <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.

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