Re: [PATCH v2 for-4.22] x86/cpu-policy: set up host policy earlier

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.07.2026 08:26, Jan Beulich wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -66,8 +66,10 @@ void __init setup_clear_cpu_cap(unsigned
>       __clear_bit(cap, boot_cpu_data.x86_capability);
>       dfs = x86_cpu_policy_lookup_deep_deps(cap);
>  
> -     if (!dfs)
> +     if (!dfs) {
> +             calculate_host_cpu_policy();
>               return;
> +     }
>  
>       for (i = 0; i < FSCAPINTS; ++i) {
>               cleared_caps[i] |= dfs[i];
> @@ -78,6 +80,8 @@ void __init setup_clear_cpu_cap(unsigned
>                      __builtin_return_address(0),
>                      i, forced_caps[i] & dfs[i]);
>       }
> +
> +     calculate_host_cpu_policy();
>  }
>  
>  void __init setup_force_cpu_cap(unsigned int cap)
> @@ -92,6 +96,8 @@ void __init setup_force_cpu_cap(unsigned
>       }
>  
>       __set_bit(cap, boot_cpu_data.x86_capability);
> +
> +     calculate_host_cpu_policy();
>  }

During the call yesterday you raised concern over the overhead these calls
may cause. How about we make this call dependent upon cap < FSCAPINTS * 32?
Synthetic features and bug flags don't have dependencies, as they don't
have representation in the policies in the first place.

Whether something similar would make sense in setup_clear_cpu_cap() I'm
inclined to question. We typically "force" synthetic features and bug
flags, while we typically "clear" bits having representation in policy.
Plus if at all such a check would then likely better live ahead of the
call to x86_cpu_policy_lookup_deep_deps() anyway.

Jan