On 19/09/2019 12:48, Jan Beulich wrote: > Recent AMD processors may report up to 128 logical processors in CPUID > leaf 1. Doubling this value produces 0 (which OSes sincerely dislike), > as the respective field is only 8 bits wide. Suppress doubling the value > (and its leaf 0x80000008 counterpart) in such a case. > > Additionally don't even do any adjustment when the host topology already > includes room for multiple threads per core. > > Furthermore don't double the Maximum Cores Per Package at all - by us > introducing a fake HTT effect, the core count doesn't need to change. > Instead adjust the Maximum Logical Processors Sharing Cache field, which > so far was zapped altogether. > > Also zap leaf 4 (and at the same time leaf 2) EDX output for AMD. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > TBD: Using xc_physinfo() output here needs a better solution. The > threads_per_core value returned is the count of active siblings of > CPU 0, rather than a system wide applicable value (and constant > over the entire session). Using CPUID output (leaves 4 and > 8000001e) doesn't look viable either, due to this not really being > the host values on PVH. Judging from the host feature set's HTT > flag also wouldn't tell us whether there actually are multiple > threads per core.
The key thing is that htt != "more than one thread per core". HTT is strictly a bit indicating that topology information is available in a new form in the CPUID leaves (or in AMDs case, the same information should be interpreted in a new way). Just because HTT is set (and it does get set in non-HT capable systems), doesn't mean there is space for more than thread per core in topology information. For PV guests, my adjustment in the CPUID series shows (what I believe to be) the only correct way of propagating the host HTT/CMP_LEGACY settings through. For HVM guests, it really shouldn't really have anything to do with the host setting. We should be choosing how many threads/core to give to the guest, then constructing the topology information from first principles. Ignore the PVH case. It is totally broken for several other reasons as well, and PVH Dom0 isn't a production-ready thing yet. This gets us back to the PV case where the host information is actually in view, and (for backport purposes) can be trusted. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
