Re: [Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC handling

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Sent: 04 March 2020 17:31
> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>; Xen-devel 
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Cc: Wei Liu <wl@xxxxxxx>; Jan Beulich <JBeulich@xxxxxxxx>; Anthony PERARD 
> <anthony.perard@xxxxxxxxxx>;
> Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Subject: RE: [EXTERNAL][Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC 
> handling
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 04/03/2020 09:33, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
> >> Andrew Cooper
> >> Sent: 03 March 2020 18:25
> >> To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> >> Cc: Wei Liu <wl@xxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Jan 
> >> Beulich
> <JBeulich@xxxxxxxx>;
> >> Anthony PERARD <anthony.perard@xxxxxxxxxx>; Ian Jackson 
> >> <Ian.Jackson@xxxxxxxxxx>; Roger Pau Monné
> >> <roger.pau@xxxxxxxxxx>
> >> 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.

Ok, as long guests running on an older Xen won't see a stable ITSC disappear 
when moved to a newer Xen then there should be no problem here.

  Paul

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