Re: [Xen-devel] [PATCH RFC] x86: Add hack to disable "Fake HT" mode

[Jürgen Groß <jgross@xxxxxxxx>]

On 15.11.19 11:57, 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 (among other things) actually reporting hyperthreading as
> available, but giving vcpus every other APICID.  The resulting cpu
> featureset is invalid, but most operating systems on most hardware
> managed to cope with it.
>
> Unfortunately, Windows running on modern AMD hardware -- including
> Ryzen 3xxx series processors, and reportedly EPYC "Rome" cpus -- gets
> confused by the resulting contradictory feature bits and crashes
> during installation.  (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,
> implement an option to disable this "Fake HT" mode.  The resulting
> topology reported will not be canonical, but experimentally continues
> to work with Windows guests.
>
> However, disabling this "Fake HT" mode has not been widely tested, and
> will almost certainly break migration if applied inconsistently.
>
> To minimize impact while allowing administrators to disable "Fake HT"
> only on guests which are known not to work without it (i.e., Windows
> guests) on affected hardware, add an environment variable which can be
> set to disable the "Fake HT" mode on such hardware.
Hmm, how is this going to work with libvirt? AFAIK libvirtd running as
a single process is creating all guests. So with this approach you'd
either not be able to use libvirtd, or you'd have to disable "Fake HT"
for all guests, probably by modifying the libvirtd service definition.

> Reported-by: Steven Haigh <netwiz@xxxxxxxxx>
> Reported-by: Andreas Kinzler <hfp@xxxxxxxxx>
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
> ---
> This has been compile-tested only; I'm posting it early to get
> feedback on the approach.
>
> TODO: Prevent such guests from being migrated
>
> Open questions:
>
> - Is this the right place to put the `getenv` check?
>
> - Is there any way we can make migration work, at least in some cases?
>
> - Can we check for known-problematic models, and at least report a
>    more useful error?
Can't we just disable "Fake HT" automatically on those models? This
would automagically make migration work, too.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel