On 18.11.2025 16:41, Andrew Cooper wrote: > On 18/11/2025 3:07 pm, Jan Beulich wrote: >> Use the respective host CPU policy bit instead. >> >> Signed-off-by: Jan Beulich <[email protected]> > > Right now, the synthetic features get levelled across the system. Now, > we take the BSP's copy. > > This change is broadly fine, but it does need mentioning in the commit > message.
"Use the respective host CPU policy bit instead. This has the (tolerable, as we generally assume symmetry anyway) effect of using the BSP's (unleveled) setting, rather than the result of leveling (as is done by identify_cpu() on boot_cpu_data, rendering the variable name somewhat misleading)." ? > One thing we may want to do is take greater care to get the > masking/levelling MSRs properly level. Right now, if they're asymmetric > for any reason, we would previously end up using the common subset. Possibly; I'd prefer to leave that to you, though. >> --- a/xen/arch/x86/include/asm/cpufeature.h >> +++ b/xen/arch/x86/include/asm/cpufeature.h >> @@ -11,7 +11,9 @@ >> #include <xen/macros.h> >> >> #ifndef __ASSEMBLY__ >> +#include <asm/cpu-policy.h> >> #include <asm/cpuid.h> >> +#include <xen/lib/x86/cpu-policy.h> > > Why both? The former declares host_cpu_policy, while the latter defines struct cpu_policy. And neither of the two #include-s the other, afaics. Jan
