|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps
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.
>
>> --- a/xen/include/asm-x86/cpuid.h
>> +++ b/xen/include/asm-x86/cpuid.h
>> @@ -103,7 +103,25 @@ struct cpuid_policy
>>
>> /* Leaf 0x1 - family/model/stepping and features. */
>> struct {
>> - uint32_t :32, :32, _1c, _1d;
>> + uint32_t :32, :32;
>> + union {
>> + uint32_t _1c;
>> + struct {
>> + bool sse3:1, pclmulqdq:1, dtes64:1, monitor:1,
>> dscpl:1, vmx:1, smx:1, eist:1,
>> + tm2:1, ssse3:1, /* cid */:1, /* sdbg */:1,
>> fma:1, cx16:1, xtpr:1, pcdm:1,
>> + :1, pcid:1, dca:1, sse4_1:1, sse4_2:1,
>> x2apic:1, movebe:1, popcnt:1,
> movbe
>
>> + tsc_deadline:1, aesni:1, xsave:1, /* osxsave
>> */:1, avx:1, f16c:1, rdrand:1, hv:1;
> hypervisor (please make sure the name match up with X86_FEATURE_*).
>
>> @@ -113,7 +131,34 @@ struct cpuid_policy
>> struct cpuid_leaf raw[CPUID_GUEST_NR_FEAT];
>> struct {
>> struct {
>> - uint32_t max_subleaf, _7b0, _7c0, _7d0;
>> + uint32_t max_subleaf;
>> + union {
>> + uint32_t _7b0;
>> + struct {
>> + bool fsgsbase:1, tsc_adjust:1, sgx:1, bmi1:1,
>> hle:1, avx2:1, fdp_excp_only:1, smep:1,
>> + bmi2:1, erms:1, invpcid:1, rtm:1, pqm:1,
>> no_fpu_sel:1, mpx:1, pqe:1,
>> + avx512f:1, avx512dq:1, rdseed:1, adx:1,
>> smap:1, avx512ifma:1, /* pcommit */:1, clflushopt:1,
>> + clwb:1, /* pt */:1, avx512pf:1, avx512er:1,
>> avx512cd:1, sha:1, avx512bw:1, avx512vl:1;
> The commented out entries here don't match the commit message.
Well - they are not yet implemented.
>
>> + };
>> + };
>> + 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.
>
>> @@ -126,7 +171,16 @@ struct cpuid_policy
>> uint32_t xcr0_low, :32, :32, xcr0_high;
>> };
>> struct {
>> - uint32_t Da1, :32, xss_low, xss_high;
>> + union {
>> + uint32_t Da1;
>> + struct {
>> + bool xsaveopt: 1, xsavec: 1, xgetbv1: 1, xsaves: 1,
>> :1, :1, :1, :1,
> Why the blanks after the colons?
Older formatting choice. I will fix up.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |