Re: [Xen-devel] [PATCH v2 for-4.11] x86/spec_ctrl: Updates to retpoline-safety decision making

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.04.18 at 16:25, <andrew.cooper3@xxxxxxxxxx> wrote:
> All of this is as recommended by the Intel whitepaper:
> 
> https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
> 
> The 'RSB Alternative' bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor
> to indicate that the virtual machine may migrate to a processor which isn't
> retpoline-safe.  Introduce a shortened name (to reduce code volume), treat it
> as authorative in retpoline_safe(), and print its value along with the other
> ARCH_CAPS bits.
> 
> The exact processor models which do have RSB semantics which fall back to BTB
> predictions are enumerated, and include Kabylake and Coffeelake.  Leave a
> printk() in the default case to help identify cases which aren't covered.
> 
> The exact microcode versions from Broadwell RSB-safety are taken from the
> referenced microcode update file (adjusting for the known-bad microcode
> versions).  Despite the exact wording of the text, it is only Broadwell
> processors which need a microcode check.
> 
> In practice, this means that all Broadwell hardware with up-to-date microcode
> will use retpoline in preference to IBRS, which will be a performance
> improvement for desktop and server systems which would previously always opt
> for IBRS over retpoline.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>



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