Re: [Xen-devel] [PATCH v2 03/12] x86: infrastructure to allow converting certain indirect calls to direct ones

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.08.18 at 16:37, <julien.grall@xxxxxxx> wrote:
> On 08/29/2018 03:02 PM, Jan Beulich wrote:
>> +#define alternative_vcall2(func, arg1, arg2) ({           \
>> +    ALT_CALL_ARG(arg1, 1);                                \
>> +    ALT_CALL_ARG(arg2, 2);                                \
> 
> I believe this code has the same issue Stefano recently discovered on 
> the SMCCC.
> 
> Using explicit register variable will not reserve the register. So if 
> arg* is a function call, the register you have just assigned will get 
> clobbered (see [1]).
> 
> The solution to this is evaluating all the arguments before declaring 
> the variable with explicit registers. See the patch [2] for an example.

Oh, I see - I should have made the connection when reading through
that part of the gcc doc the other day. The current construct is safe
for all current uses, but I agree I'd better follow the model you point
out.

>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -66,6 +66,10 @@
>>   
>>   #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
>>   
>> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x
>> +#define count_va_arg(args...) \
>> +    count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0)
> 
> We have a similar function in SMCCC where only the arguments except the 
> first one (Function ID) and last one (Result pointer). I believe 
> different context will require different way to count argument in order 
> to keep the code readable.
> 
> So I am not entirely sure if there are a benefit to have this function 
> in common.

From an initial look it seemed to me that the SMCCC code could be
converted to use the macros here. In any event, other than the
macros used there the ones here are generic in that they simply
could arguments, without and special treatment of any of them.
Hence the generic name and placement.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel