Re: [PATCH RFC 01/31] xen/public: Export featureset information in the public API

["Jan Beulich" <jbeulich@suse.com>]

>>> Andrew Cooper <andrew.cooper3@citrix.com> 12/23/15 11:05 AM >>>
>On 22/12/2015 16:59, Jan Beulich wrote:
>>>>> On 22.12.15 at 17:42, <andrew.cooper3@citrix.com> wrote:
>>> On 22/12/15 16:28, Jan Beulich wrote:
>>>>>>> On 16.12.15 at 22:24, <andrew.cooper3@citrix.com> wrote:
>>>>> +#define XEN_FEATURESET_1d     0 /* 0x00000001.edx      */
>>>>> +#define XEN_FEATURESET_1c     1 /* 0x00000001.ecx      */
>>>>> +#define XEN_FEATURESET_e1d    2 /* 0x80000001.edx      */
>>>>> +#define XEN_FEATURESET_e1c    3 /* 0x80000001.ecx      */
>>>>> +#define XEN_FEATURESET_Da1    4 /* 0x0000000d:1.eax    */
>>>>> +#define XEN_FEATURESET_7b0    5 /* 0x00000007:0.ebx    */
>>>> This ends up being pretty cryptic.
>>> Perhaps at a first glance, but there are so many uses that a shorthand
>>> really is needed.  See especially the MSR masking patches towards the
>>> end of the series.
>> I understand that something short is needed. But as the main
>> identifier in the ABI?
>
>It really comes down to whom is intended to do what with a featureset.
>
>These values are derivable as functions of the feature values
>themselves, but that requires an assumption that the featureset bitmap
>mirrors hardware precisely.  Providing this (names not withstanding) as
>a part of the ABI is intended to provide that assurance.
>
>I fully intend higher levels of the toolstack to deal with a featureset
>as an arbitrary bitmap, but lower levels like libxc do need a greater
>level of understanding of its layout.

All understood. The question just is whether the main identifiers in the public
header should be this cryptic, or whether consumers should instead introduce
shortcuts of their liking (even more so that, just like noted elsewhere, these
identifiers also lack "CPU" and perhaps "x86" in their names - in the end
feature leveling isn't something that's needed on x86 only).

Jan