[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 06/10] x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants
>>> On 15.05.18 at 21:52, <andrew.cooper3@xxxxxxxxxx> wrote: > On 14/05/18 16:27, Jan Beulich wrote: >>>>> On 11.05.18 at 12:38, <andrew.cooper3@xxxxxxxxxx> 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. Ah yes, indeed. And you would better use alternative_input() there then, instead of open coding it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |