Re: [PATCH 2/6] x86/cpuid: Introduce recalculate_xstate()

From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 2/6] x86/cpuid: Introduce recalculate_xstate()
Date: Mon, 16 Jan 2017 10:09:43 -0700	[thread overview]
Message-ID: <587D0C670200007800130A0E@prv-mh.provo.novell.com> (raw)
In-Reply-To: <0af7c8ab-3e5f-0f72-d5e9-0e1aafeed530@citrix.com>

>>> On 16.01.17 at 18:02, <andrew.cooper3@citrix.com> wrote:
> On 16/01/17 16:45, Jan Beulich wrote:
>>>>> On 16.01.17 at 12:40, <andrew.cooper3@citrix.com> wrote:
>>> @@ -154,6 +152,13 @@ struct cpuid_policy
>>>              };
>>>              uint32_t /* b */:32, xss_low, xss_high;
>>>          };
>>> +
>>> +        /* Per-component common state.  Valid for i >= 2. */
>>> +        struct {
>>> +            uint32_t size, offset;
>>> +            bool xss:1, align:1;
>>> +            uint32_t /* c */:30, /* d */:32;
>>> +        } comp[CPUID_GUEST_NR_XSTATE];
>> Hmm, can we rely on this functioning on varying complier variants?
>> I think the standard doesn't exclude a uint32_t type bitfield to
>> start on a 4-byte boundary if not following another uint32_t one.
>> IOW I think we'd be better off giving the same type to all fields we
>> want to share a storage unit.
> 
> Hmm.  In this case, something like:
> 
> bool xss:1, align:1;
> uint32_t _res_d;
> 
> ought to work.

In a union you mean? Yes.

Jan

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