On 14/05/18 16:27, Jan Beulich wrote: >>>> On 11.05.18 at 12:38, <andrew.coop...@citrix.com> wrote: >> --- a/xen/arch/x86/spec_ctrl.c >> +++ b/xen/arch/x86/spec_ctrl.c >> @@ -128,7 +128,8 @@ static void __init print_details(enum ind_thunk thunk, >> uint64_t caps) >> thunk == THUNK_RETPOLINE ? "RETPOLINE" : >> thunk == THUNK_LFENCE ? "LFENCE" : >> thunk == THUNK_JMP ? "JMP" : "?", >> - boot_cpu_has(X86_FEATURE_SC_MSR) ? >> + (boot_cpu_has(X86_FEATURE_SC_MSR_PV) || >> + boot_cpu_has(X86_FEATURE_SC_MSR_HVM)) ? >> default_xen_spec_ctrl & SPEC_CTRL_IBRS ? " IBRS+" : >> " IBRS-" : "", >> opt_ibpb ? " IBPB" : "", >> @@ -367,7 +368,8 @@ void __init init_speculation_mitigations(void) >> * need the IBRS entry/exit logic to virtualise IBRS support for >> * guests. >> */ >> - setup_force_cpu_cap(X86_FEATURE_SC_MSR); >> + setup_force_cpu_cap(X86_FEATURE_SC_MSR_PV); >> + setup_force_cpu_cap(X86_FEATURE_SC_MSR_HVM); > Besides these sort of open coding alternative_io_2() (you'd really want an > output-less variant here, I agree) these are slightly bending the rules of > when/how to use multiple alternatives: The above ends up correct only > because of both replacements being identical.
Actually, by reordering patch 10 ahead of this patch, we never get to needing the ALTERNATIVE_2()'s in the first place, and lose any concerns with bending the rules along the series. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
