|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC] x86: Don't increase ApicIdCoreSize past 7
On 25.11.2019 13:39, George Dunlap wrote:
> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
> guests") attempted to "fake up" a topology which would induce guest
> operating systems to not treat vcpus as sibling hyperthreads. This
> involved actually reporting hyperthreading as available, but giving
> vcpus every other ApicId; which in turn led to doubling the ApicIds
> per core by bumping the ApicIdCoreSize by one. In particular, Ryzen
> 3xxx series processors, and reportedly EPYC "Rome" cpus -- have an
> ApicIdCoreSize of 7; the "fake" topology increases this to 8.
>
> Unfortunately, Windows running on modern AMD hardware -- including
> Ryzen 3xxx series processors, and reportedly EPYC "Rome" cpus --
> doesn't seem to cope with this value being higher than 7. (Linux
> guests have so far continued to cope.)
>
> A "proper" fix is complicated and it's too late to fix it either for
> 4.13, or to backport to supported branches. As a short-term fix,
> limit this value to 7.
>
> This does mean that a Linux guest, booted on such a system without
> this change, and then migrating to a system with this change, with
> more than 64 vcpus, would see an apparent topology change. This is a
> low enough risk in practice that enabling this limit unilaterally, to
> allow other guests to boot without manual intervention, is worth it.
>
> Reported-by: Steven Haigh <netwiz@xxxxxxxxx>
> Reported-by: Andreas Kinzler <hfp@xxxxxxxxx>
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
with ...
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -616,10 +616,15 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> domid,
> * - going out of sync with leaf 1 EBX[23:16],
> * - incrementing ApicIdCoreSize when it's zero (which changes
> the
> * meaning of bits 7:0).
> + *
> + * UPDATE: I addition to avoiding overflow, some
... this becoming "UPDATE: In ...".
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |