[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 22.12.15 at 17:42, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/12/15 16:28, Jan Beulich wrote:
>>>>> On 16.12.15 at 22:24, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, FSMAX+2 
>>> */
>>> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore 
>>> insn) */
>>> +#define X86_FEATURE_XSTORE_EN      ((FSMAX+1)*32+ 3) /* on-CPU RNG enabled 
>>> */
>>> +#define X86_FEATURE_XCRYPT ((FSMAX+1)*32+ 6) /* on-CPU crypto (xcrypt 
>>> insn) */
>>> +#define X86_FEATURE_XCRYPT_EN      ((FSMAX+1)*32+ 7) /* on-CPU crypto 
>>> enabled */
>>> +#define X86_FEATURE_ACE2   ((FSMAX+1)*32+ 8) /* Advanced Cryptography 
>>> Engine v2 */
>>> +#define X86_FEATURE_ACE2_EN        ((FSMAX+1)*32+ 9) /* ACE v2 enabled */
>>> +#define X86_FEATURE_PHE            ((FSMAX+1)*32+10) /* PadLock Hash 
>>> Engine */
>>> +#define X86_FEATURE_PHE_EN ((FSMAX+1)*32+11) /* PHE enabled */
>>> +#define X86_FEATURE_PMM            ((FSMAX+1)*32+12) /* PadLock Montgomery 
>>> Multiplier */
>>> +#define X86_FEATURE_PMM_EN ((FSMAX+1)*32+13) /* PMM enabled */
>> None of these get consumed anywhere - if you already touch this
>> code, just drop all of them.
> 
> X86_FEATURE_XSTORE gets used in xen/arch/x86/cpu/centaur.c to stash word
> 0xC0000001, but nothing actually reads the stashed values.
> 
> I could do a precursor patch which drops the stashing of this
> information, which will result in NCAPINTS getting shorter by the end of
> the series.

Yes, that's what I meant to imply.

>>> +/*
>>> + * CPUID leaf shorthand:
>>> + * - optional 'e', Extended (0x8xxxxxxx)
>>> + * - leaf, uppercase hex
>>> + * - register, lowercase
>>> + * - optional subleaf, uppercase hex
>>> + */
>>> +#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?

>>> +#define XEN_NR_FEATURESET_ENTRIES (XEN_FEATURESET_7b0 + 1)
>> This shouldn't be exposed, as it will necessarily change sooner or later.
> 
> Hmm yes - I think I can alter where this lives, although libxc does need
> to be able to get this value.

Perhaps keep it where it is, but put it inside #ifdef __XEN__?

Jan


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


 


Rackspace

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