On 04/03/2020 09:33, Durrant, Paul wrote: >> -----Original Message----- >> From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Andrew >> Cooper >> Sent: 03 March 2020 18:25 >> To: Xen-devel <xen-devel@lists.xenproject.org> >> Cc: Wei Liu <w...@xen.org>; Andrew Cooper <andrew.coop...@citrix.com>; Jan >> Beulich <jbeul...@suse.com>; >> Anthony PERARD <anthony.per...@citrix.com>; Ian Jackson >> <ian.jack...@citrix.com>; Roger Pau Monné >> <roger....@citrix.com> >> Subject: [Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC handling >> >> ITSC being visible to the guest is currently implicit with the toolstack >> unconditionally asking for it, and Xen clipping it based on the vTSC and/or >> XEN_DOMCTL_disable_migrate settings. >> >> This is problematic for several reasons. >> >> First, the implicit vTSC behaviour manifests as a real bug on migration to a >> host with a different frequency, with ITSC but without TSC scaling >> capabilities, whereby the ITSC feature becomes advertised to the guest. ITSC >> will disappear again if the guest migrates to server with the same frequency >> as the original, or to one with TSC scaling support. >> >> Secondly, disallowing ITSC unless the guest doesn't migrate is conceptually >> wrong. It is common to have migration pools of identical hardware, at which >> point the TSC frequency is the same, and more modern hardware has TSC scaling >> support anyway. In both cases, it is safe to advertise ITSC and migrate the >> guest. >> >> Remove all implicit logic logic in Xen, and make ITSC part of the max CPUID > One too many 'logic's there.
Oops. > >> policies for guests. Plumb an itsc parameter into xc_cpuid_apply_policy() >> and >> have libxl__cpuid_legacy() fill in the two cases where it can reasonably >> expect ITSC to be safe for the guest to see. >> >> This is a behaviour change for TSC_MODE_NATIVE, where the ITSC will now >> reliably not appear, and for the case where the user explicitly requests >> ITSC, >> in which case it will appear even if the guest isn't marked as nomigrate. >> > Does this mean a guest that would have seen ITSC on 4.13 may now no longer > see it in 4.14 or is the TSC_MODE_NATIVE case just the one where the feature > may erroneously appear after migration? In general, guests don't get to see ITSC at all, even before this change. This is something which needs working on, but it is only a tractable problem in a multi-host toolstack. After this change, the TSC_MODE_NATIVE case will now not see a metastable ITSC feature depending on the properties of the host it happens to be on. It will default to consistently 0, unless overridden by the toolstack. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
