Re: [Xen-devel] [PATCH v2 09/30] xen/x86: Store antifeatures inverted in a featureset

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.02.16 at 17:50, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/02/16 16:47, Jan Beulich wrote:
>>>>> On 05.02.16 at 14:42, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Awkwardly, some new feature bits mean "Feature $X no longer works".
>>> Store these inverted in a featureset.
>>>
>>> This permits safe zero-extending of a smaller featureset as part of a
>>> comparison, and safe reasoning (subset?, superset?, compatible? etc.)
>>> without specific knowldge of meaning of each bit.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Acked-by: Jan Beulich <JBeulich@xxxxxxxx>
>> albeit ...
>>
>>> @@ -158,7 +174,7 @@
>>>  #define X86_FEATURE_INVPCID       ( 5*32+10) /*   Invalidate Process 
>>> Context ID */
>>>  #define X86_FEATURE_RTM           ( 5*32+11) /*   Restricted Transactional 
>>> Memory */
>>>  #define X86_FEATURE_CMT           ( 5*32+12) /*   Cache Monitoring 
>>> Technology */
>>> -#define X86_FEATURE_NO_FPU_SEL    ( 5*32+13) /*   FPU CS/DS stored as zero 
>>> */
>>> +#define X86_FEATURE_FPU_SEL       ( 5*32+13) /*!  FPU CS/DS stored as zero 
>>> */
>> ... changes like this to the public interface should normally be
>> avoided (i.e. you had better left out the "NO" one when you first
>> created this file).
> 
> I couldn't find a neater way of doing this while keeping the name
> consistent with its representation.  I took the decision that this is
> the lesser of the available evils when making this change.
> 
> I am open to alternate suggestions.

How about you keep it in asm-x86/cpufeatures.h prior to this
patch? But it's not really a big deal provided the series up to
here goes in more or less at the same time...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel