On 04/03/2024 8:42 am, Jan Beulich wrote: > 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.
This patch doesn't change the default at all. All it does is expose (properly) in the max policy what Xen would tolerate the toolstack doing blindly. If there are problems in certain configurations, then they continue to be problems. Although I'll note that the unconditional multiplying by 2 was never about hyper-threading - Alejandro did some archaeology and found out that it was an LAPIC vs IOAPIC error in vmxloader. The connection to HT has just been bad guesswork since. ~Andrew
