Re: [Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/01/17 08:27, Jan Beulich wrote:
>>>> On 04.01.17 at 18:21, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 04/01/17 15:44, Jan Beulich wrote:
>>>>>> On 04.01.17 at 13:39, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> Use anonymous unions to access the feature leaves as complete words, and by
>>>> named individual feature.
>>>>
>>>> A feature name is introduced for every architectural X86_FEATURE_*, other 
>>>> than
>>>> the dynamically calculated values such as APIC, OSXSAVE and OSPKE.
>>> A rationale for this change would be nice to have here, as the
>>> redundancy with public/arch-x86/cpufeatureset.h means any
>>> addition will now need to change two places. Would it be possible
>>> for gen-cpuid.py to generate these bitfield declarations?
>> Hmm.  I hadn't considered that as an option.
>>
>> Thinking about it however, I'd ideally prefer not to hide the
>> declarations behind a macro.
> What's wrong with that?

My specific dislike of hiding code from tools like grep and cscope.

> It's surely better than having to keep two pieces of code in sync manually.

True, but that doesn't come with zero cost.

Thinking about it, the spanner in the works for easily generating this
in an automatic way is MAWAU in leaf 7, which is the first non-bit thing
in the feature leaves.

>>>> +                    };
>>>> +                };
>>>> +                union {
>>>> +                    uint32_t _7c0;
>>>> +                    struct {
>>>> +                        bool prefetchwt1:1, avx512vbmi:1, :1, pku: 1, :1, 
>>>> :1, :1, :1,
>>>> +                             :1, :1, :1, :1, :1, :1, :1, :1,
>>>> +                             :1, :1, :1, :1, :1, :1, :1, :1,
>>>> +                             :1, :1, :1, :1, :1, :1, :1, :1;
>>> This is ugly, but I remember you saying (on irc?) the compiler
>>> doesn't allow bitfields wider than one bit for bool ...
>> Correct.  I was quite surprised by this, but I can understand that bool
>> foo:2 is quite meaningless when foo can strictly only take a binary value.
> Thinking about it another time - what's wrong with using uint32_t
> instead of bool here, allowing consecutive unknown fields to be
> folded?

I first tried using uint32_t and had many problems counting bits
(although this less of an issue if it was automatically generated).

I also wanted to maintain bool properties, but now I think back, I don't
forsee any situation where we would make an assignment to one of these
named features.

~Andrew

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