Re: [Xen-devel] [PATCH v2 29/30] tools/libxc: Use featuresets rather than guesswork

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.02.16 at 14:03, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 17/02/16 08:55, Jan Beulich wrote:
>>>>> On 05.02.16 at 14:42, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> @@ -467,11 +420,8 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
>>>          regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
>>>          break;
>>>      case 1: /* leaf 1 */
>>> -        regs[0] &= (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES);
>>> -        if ( !info->hvm )
>>> -            regs[0] &= ~XSAVES;
>>> -        regs[2] &= info->xfeature_mask;
>>> -        regs[3] = 0;
>>> +        regs[0] = info->featureset[featureword_of(X86_FEATURE_XSAVEOPT)];
>>> +        regs[1] = regs[2] = regs[3] = 0;
>>>          break;
>> This change (to regs[2] handling) reminds me of an apparent issue
>> in the earlier dependencies patch, which I realized only after having
>> sent the reply, and then forgot to send another reply for: Shouldn't
>> features requiring certain XSAVE states depend on that state's
>> availability instead of just XSAVE? That would make the above use
>> proper masking for both regs[2] and regs[3] (and also for regs[0]
>> and regs[3] in the sub-leaf 0 case).
> 
> Have you looks at this patch in combination with the following one?

I did look at the next one only after writing this reply, but with
that one not again changing sub-leaf 1 handling I don't see why
this would make a difference.

> Strictly speaking, there is a difference between the xstate availability
> and the features which use them.  However, the former are not level-able
> on older hardware.  I have deliberately constructed the former from the
> latter, to prevent the two becoming different, and unlike real hardware.

You mean this

+    guest_xfeature_mask = X86_XCR0_SSE | X86_XCR0_X87;
+
+    if ( test_bit(X86_FEATURE_AVX, info->featureset) )
+        guest_xfeature_mask |= X86_XCR0_AVX;
+
+    if ( test_bit(X86_FEATURE_LWP, info->featureset) )
+        guest_xfeature_mask |= X86_XCR0_LWP;

I guess? That's exactly what I've been talking about: You make
everything else come from the hypervisor - why not this mask
too (at once avoiding the need to fiddle with this code for each
new state component)? It would just be two more array elements
for sub-leaf 0 EDX:EAX and maybe another two for sub-leaf 1
EDX:ECX (they could really be combined, since the two bit masks
are exclusive of one another). And perhaps there should then
be a bi-directional dependency: CPUID[BASE].AVX (for example)
should depend on CPUID[XSAVE].AVX and vice versa.

Jan


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