On 19/04/18 16:25, Andrew Cooper 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.coop...@citrix.com>
Release-acked-by: Juergen Gross <jgr...@suse.com> Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
