[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 01/11] is_control_domain: block speculation
>>> On 23.01.19 at 14:20, <julien.grall@xxxxxxx> wrote: > On 23/01/2019 13:07, Jan Beulich wrote: >>>>> On 23.01.19 at 12:51, <nmanthey@xxxxxxxxx> wrote: >>> --- a/xen/include/xen/nospec.h >>> +++ b/xen/include/xen/nospec.h >>> @@ -58,6 +58,21 @@ static inline unsigned long >>> array_index_mask_nospec(unsigned long index, >>> (typeof(_i)) (_i & _mask); \ >>> }) >>> >>> +/* >>> + * allow to insert a read memory barrier into conditionals >>> + */ >> >> Please obey to the comment style set forth in ./CODING_STYLE. >> >>> +#ifdef CONFIG_X86 >>> +static inline bool lfence_true(void) { rmb(); return true; } >>> +#else >>> +static inline bool lfence_true(void) { return true; } >>> +#endif >> >> This is a generic header, hence functions defined here should have >> universally applicable names. "lfence", however, is an x86 term >> (naming a particular instruction). I can't think of really good >> alternatives, but how about one of arch_nospec_true() / >> arch_fence_nospec_true() / arch_nospec_fence_true()? > > We seems to use more the term "barrier" in common code over "fence". So how > about arch_barrier_nospec_true/arch_nospec_barrier_true? That would be fine with me as well. 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 |