Use the respective host CPU policy bit instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -523,10 +523,6 @@ static void generic_identify(struct cpui
 	if ( cpu_has(c, X86_FEATURE_CLFLUSH) )
 		c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8;
 
-	if ( (c->cpuid_level >= CPUID_PM_LEAF) &&
-	     (cpuid_ecx(CPUID_PM_LEAF) & CPUID6_ECX_APERFMPERF_CAPABILITY) )
-		__set_bit(X86_FEATURE_APERFMPERF, c->x86_capability);
-
 	/* AMD-defined flags: level 0x80000001 */
 	if (c->extended_cpuid_level >= 0x80000001)
 		cpuid(0x80000001, &tmp, &tmp,
--- 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>
 #else
 #include <asm/cpufeatureset.h>
 #endif
@@ -121,7 +123,6 @@ static inline bool boot_cpu_has(unsigned
 #define CPUID6_EAX_HDC                               BIT(13, U)
 #define CPUID6_EAX_HWP_PECI                          BIT(16, U)
 #define CPUID6_EAX_HW_FEEDBACK                       BIT(19, U)
-#define CPUID6_ECX_APERFMPERF_CAPABILITY             BIT(0, U)
 
 /* CPUID level 0x00000001.edx */
 #define cpu_has_fpu             1
@@ -175,6 +176,9 @@ static inline bool boot_cpu_has(unsigned
 #define cpu_has_fma4            boot_cpu_has(X86_FEATURE_FMA4)
 #define cpu_has_tbm             boot_cpu_has(X86_FEATURE_TBM)
 
+/* CPUID level 0x00000006.ecx */
+#define cpu_has_aperfmperf      host_cpu_policy.basic.pm.aperfmperf
+
 /* CPUID level 0x0000000D:1.eax */
 #define cpu_has_xsaveopt        boot_cpu_has(X86_FEATURE_XSAVEOPT)
 #define cpu_has_xsavec          boot_cpu_has(X86_FEATURE_XSAVEC)
@@ -292,7 +296,6 @@ static inline bool boot_cpu_has(unsigned
 /* Synthesized. */
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)
 #define cpu_has_cpuid_faulting  boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
-#define cpu_has_aperfmperf      boot_cpu_has(X86_FEATURE_APERFMPERF)
 #define cpu_has_xen_lbr         boot_cpu_has(X86_FEATURE_XEN_LBR)
 #define cpu_has_xen_shstk       (IS_ENABLED(CONFIG_XEN_SHSTK) && \
                                  boot_cpu_has(X86_FEATURE_XEN_SHSTK))
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -19,7 +19,7 @@ XEN_CPUFEATURE(TSC_RELIABLE,      X86_SY
 XEN_CPUFEATURE(XTOPOLOGY,         X86_SYNTH( 5)) /* cpu topology enum extensions */
 XEN_CPUFEATURE(CPUID_FAULTING,    X86_SYNTH( 6)) /* cpuid faulting */
 XEN_CPUFEATURE(XEN_FRED,          X86_SYNTH( 7)) /* Xen uses FRED */
-XEN_CPUFEATURE(APERFMPERF,        X86_SYNTH( 8)) /* APERFMPERF */
+/* Bit 8 unused */
 XEN_CPUFEATURE(MFENCE_RDTSC,      X86_SYNTH( 9)) /* MFENCE synchronizes RDTSC */
 XEN_CPUFEATURE(XEN_SMEP,          X86_SYNTH(10)) /* SMEP gets used by Xen itself */
 XEN_CPUFEATURE(XEN_SMAP,          X86_SYNTH(11)) /* SMAP gets used by Xen itself */

On 18/11/2025 3:07 pm, Jan Beulich wrote:
> Use the respective host CPU policy bit instead.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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.

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.

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -523,10 +523,6 @@ static void generic_identify(struct cpui
>  	if ( cpu_has(c, X86_FEATURE_CLFLUSH) )
>  		c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8;
>  
> -	if ( (c->cpuid_level >= CPUID_PM_LEAF) &&
> -	     (cpuid_ecx(CPUID_PM_LEAF) & CPUID6_ECX_APERFMPERF_CAPABILITY) )
> -		__set_bit(X86_FEATURE_APERFMPERF, c->x86_capability);
> -
>  	/* AMD-defined flags: level 0x80000001 */
>  	if (c->extended_cpuid_level >= 0x80000001)
>  		cpuid(0x80000001, &tmp, &tmp,
> --- 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?

~Andrew

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 <jbeulich@suse.com>
> 
> 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