Re: [Xen-devel] [PATCH v4 26/26] tools/libxc: Calculate xstate cpuid leaf from guest information

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 04/05/16 7:49 PM >>>
>On 31/03/16 08:48, Jan Beulich wrote:
>>>>> On 23.03.16 at 17:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>      switch ( input[1] )
>>>      {
>>> -    case 0: 
>>> +    case 0:
>>>          /* EAX: low 32bits of xfeature_enabled_mask */
>>> -        regs[0] = info->xfeature_mask & 0xFFFFFFFF;
>>> +        regs[0] = guest_xfeature_mask;
>>          /* EDX: high 32bits of xfeature_enabled_mask */
>> -        regs[3] = (info->xfeature_mask >> 32) & 0xFFFFFFFF;
>> +        regs[3] = guest_xfeature_mask >> 32;
>> ... here and ...
>>
>>>      case 1: /* leaf 1 */
<>>          regs[0] = info->featureset[featureword_of(X86_FEATURE_XSAVEOPT)];
>>> -        regs[2] &= info->xfeature_mask;
>>> -        regs[3] = 0;
>>> +        regs[2] = guest_xfeature_mask & X86_XSS_MASK;
>>> +        regs[3] = (guest_xfeature_mask >> 32) & X86_XSS_MASK;
>> ... here. Yet not by a compile time defined mask, but by using
>> (host) CPUID output: It is clear that once a bit got assigned to XCR0
>> vs XSS, it won't ever change. Hence it doesn't matter whether you
>> use the guest or host view of that split. And this will then also - other
>> than you've said before would be unavoidable - make unnecessary to
>> always update this code when new states get added.
>
>There is no possible way of avoiding having a whitelist somewhere, which
>limits what Xen will tolerate supporting for the guest.

Right, but preferably in exactly one place. And imo that ought to be
info->xfeature_mask.

Jan


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