On 05.05.2021 16:53, Andrew Cooper wrote:
> On 05/05/2021 09:19, Jan Beulich wrote:
>> On 04.05.2021 15:58, Andrew Cooper wrote:
>>> On 04/05/2021 13:43, Jan Beulich wrote:
I'm also not happy at all to see you use a literal 3 here. We have
a struct for this, after all.
>
On 05/05/2021 09:19, Jan Beulich wrote:
> On 04.05.2021 15:58, Andrew Cooper wrote:
>> On 04/05/2021 13:43, Jan Beulich wrote:
>>> I'm also not happy at all to see you use a literal 3 here. We have
>>> a struct for this, after all.
>>>
p->xstate.xss_low = xstates & XSTATE_XSAVES_ON
On 04.05.2021 15:58, Andrew Cooper wrote:
> On 04/05/2021 13:43, Jan Beulich wrote:
>> On 03.05.2021 17:39, Andrew Cooper wrote:
>>> Make use of the new xstate_uncompressed_size() helper rather than
>>> maintaining
>>> the running calculation while accumulating feature components.
>>>
>>> The rest
On 04/05/2021 13:43, Jan Beulich wrote:
> On 03.05.2021 17:39, Andrew Cooper wrote:
>> Make use of the new xstate_uncompressed_size() helper rather than maintaining
>> the running calculation while accumulating feature components.
>>
>> The rest of the CPUID data can come direct from the raw cpuid
On 03.05.2021 17:39, Andrew Cooper wrote:
> Make use of the new xstate_uncompressed_size() helper rather than maintaining
> the running calculation while accumulating feature components.
>
> The rest of the CPUID data can come direct from the raw cpuid policy. All
> per-component data forms an AB
Make use of the new xstate_uncompressed_size() helper rather than maintaining
the running calculation while accumulating feature components.
The rest of the CPUID data can come direct from the raw cpuid policy. All
per-component data forms an ABI through the behaviour of the X{SAVE,RSTOR}*
instru