Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Andrew Cooper]

On 13/02/18 14:22, Jan Beulich wrote:
 On 12.02.18 at 12:23,  wrote:
>> --- a/xen/include/asm-x86/alternative.h
>> +++ b/xen/include/asm-x86/alternative.h
>> @@ -65,11 +65,6 @@ extern void alternative_instructions(void);
>>  ALTERNATIVE(oldinstr, newinstr1, feature1)\
>>  ALTERNATIVE_N(newinstr2, feature2, 2)
>>  
>> -#define ALTERNATIVE_3(oldinstr, newinstr1, feature1, newinstr2, feature2, \
>> -  newinstr3, feature3)\
>> -ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
>> -ALTERNATIVE_N(newinstr3, feature3, 3)
>> -
>>  /*
>>   * Alternative instructions for different CPU types or capabilities.
>>   *
> While this one is fine, ...
>
>> @@ -118,26 +113,6 @@ extern void alternative_instructions(void);
>> newinstr2, feature2) \
>>   : output : input)
>>  
>> -/*
>> - * This is similar to alternative_io. But it has three features and
>> - * respective instructions.
>> - *
>> - * If CPU has feature3, newinstr3 is used.
>> - * Otherwise, if CPU has feature2, newinstr2 is used.
>> - * Otherwise, if CPU has feature1, newinstr1 is used.
>> - * Otherwise, oldinstr is used.
>> - */
>> -#define alternative_io_3(oldinstr, newinstr1, feature1, newinstr2,  \
>> - feature2, newinstr3, feature3, output, \
>> - input...)  \
>> -asm volatile(ALTERNATIVE_3(oldinstr, newinstr1, feature1,   \
>> -   newinstr2, feature2, newinstr3,  \
>> -   feature3)\
>> - : output : input)
>> -
>> -/* Use this macro(s) if you need more than one output parameter. */
>> -#define ASM_OUTPUT2(a...) a
> ... I'm having patches to post which use both of these, so I'd
> very much prefer them to not go away. It is simply a lack of time
> which resulted in me not having posted that series already.

In which case I'll need to review that patch before commenting on this
one (i.e. whether it actually needs to be an alternative_3, or whether
there is a shorter way to do it).

The problem is that the gas_max() expression expands its parameters 5
times, and ISTR a report on LKML saying that older version of GAS
couldn't cope with the eventual expansion of the 3-replacement version.

~Andrew

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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Jan Beulich]

>>> On 12.02.18 at 12:23,  wrote:
> --- a/xen/include/asm-x86/alternative.h
> +++ b/xen/include/asm-x86/alternative.h
> @@ -65,11 +65,6 @@ extern void alternative_instructions(void);
>   ALTERNATIVE(oldinstr, newinstr1, feature1)\
>   ALTERNATIVE_N(newinstr2, feature2, 2)
>  
> -#define ALTERNATIVE_3(oldinstr, newinstr1, feature1, newinstr2, feature2, \
> -   newinstr3, feature3)\
> - ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
> - ALTERNATIVE_N(newinstr3, feature3, 3)
> -
>  /*
>   * Alternative instructions for different CPU types or capabilities.
>   *

While this one is fine, ...

> @@ -118,26 +113,6 @@ extern void alternative_instructions(void);
>  newinstr2, feature2) \
>: output : input)
>  
> -/*
> - * This is similar to alternative_io. But it has three features and
> - * respective instructions.
> - *
> - * If CPU has feature3, newinstr3 is used.
> - * Otherwise, if CPU has feature2, newinstr2 is used.
> - * Otherwise, if CPU has feature1, newinstr1 is used.
> - * Otherwise, oldinstr is used.
> - */
> -#define alternative_io_3(oldinstr, newinstr1, feature1, newinstr2,   \
> -  feature2, newinstr3, feature3, output, \
> -  input...)  \
> - asm volatile(ALTERNATIVE_3(oldinstr, newinstr1, feature1,   \
> -newinstr2, feature2, newinstr3,  \
> -feature3)\
> -  : output : input)
> -
> -/* Use this macro(s) if you need more than one output parameter. */
> -#define ASM_OUTPUT2(a...) a

... I'm having patches to post which use both of these, so I'd
very much prefer them to not go away. It is simply a lack of time
which resulted in me not having posted that series already.

Jan


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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Andrew Cooper]

On 12/02/18 15:56, Roger Pau Monné wrote:
> On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote:
>> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to
>> calculating extra padding length, and we have no need for the complexity.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
>
> I guess you also don't foresee any new features requiring this
> functionality?
>
> I assume this was added because the alternatives framework was picked
> wholesale from Linux, but we have diverged enough that we don't plan
> to sync anymore with Linux?

Linux has dropped it as well.  If we find a usecase, we can reintroduce
it, but someone is going to have some "fun" with max() handling.

~Andrew

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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote:
> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to
> calculating extra padding length, and we have no need for the complexity.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

I guess you also don't foresee any new features requiring this
functionality?

I assume this was added because the alternatives framework was picked
wholesale from Linux, but we have diverged enough that we don't plan
to sync anymore with Linux?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote:
> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to
> calculating extra padding length, and we have no need for the complexity.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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