[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.