On 01.03.2024 12:28, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu-policy.c > +++ b/xen/arch/x86/cpu-policy.c > @@ -464,6 +464,16 @@ static void __init > guest_common_max_feature_adjustments(uint32_t *fs) > raw_cpu_policy.feat.clwb ) > __set_bit(X86_FEATURE_CLWB, fs); > } > + > + /* > + * Topology information inside the guest is entirely at the toolstack's > + * disgression, and bears no relationship to the host we're running on. > + * > + * HTT identifies p->basic.lppp as valid > + * CMP_LEGACY identifies p->extd.nc as valid > + */ > + __set_bit(X86_FEATURE_HTT, fs); > + __set_bit(X86_FEATURE_CMP_LEGACY, fs); > } > > static void __init guest_common_default_feature_adjustments(uint32_t *fs) > @@ -514,6 +524,18 @@ static void __init > guest_common_default_feature_adjustments(uint32_t *fs) > __clear_bit(X86_FEATURE_CLWB, fs); > } > > + /* > + * Topology information is at the toolstack's discretion so these are > + * unconditionally set in max, but pick a default which matches the host. > + */ > + __clear_bit(X86_FEATURE_HTT, fs); > + if ( cpu_has_htt ) > + __set_bit(X86_FEATURE_HTT, fs); > + > + __clear_bit(X86_FEATURE_CMP_LEGACY, fs); > + if ( cpu_has_cmp_legacy ) > + __set_bit(X86_FEATURE_CMP_LEGACY, fs);
When running on a host with the respective bit clear, won't this break (at least older) Linux'es logic? Iirc the unconditional setting of at least HTT was tied to the unconditional multiplying by 2 of the vCPU ID to derive the (fake) APIC ID. Jan
