Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.02.16 at 17:09, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 15/02/16 15:52, Jan Beulich wrote:
>>
>>>>> --- a/xen/tools/gen-cpuid.py
>>>>> +++ b/xen/tools/gen-cpuid.py
>>>>> @@ -138,6 +138,61 @@ def crunch_numbers(state):
>>>>>      state.hvm_shadow = featureset_to_uint32s(state.raw_hvm_shadow, 
>>> nr_entries)
>>>>>      state.hvm_hap = featureset_to_uint32s(state.raw_hvm_hap, nr_entries)
>>>>>  
>>>>> +    deps = {
>>>>> +        XSAVE:
>>>>> +        (XSAVEOPT, XSAVEC, XGETBV1, XSAVES, AVX, MPX),
>>>>> +
>>>>> +        AVX:
>>>>> +        (FMA, FMA4, F16C, AVX2, XOP),
>>>> I continue to question whether namely XOP, but perhaps also the
>>>> others here except maybe AVX2, really is depending on AVX, and
>>>> not just on XSAVE.
>>> I am sure we have had this argument before.
>> Indeed, hence the "I continue to ...".
>>
>>> All VEX encoded SIMD instructions (including XOP which is listed in the
>>> same category by AMD) are specified to act on 256bit AVX state, and
>>> require AVX enabled in xcr0 to avoid #UD faults.  This includes VEX
>>> instructions encoding %xmm registers, which explicitly zero the upper
>>> 128bits of the associated %ymm register.
>>>
>>> This is very clearly a dependency on AVX, even if it isn't written in
>>> one clear concise statement in the instruction manuals.
>> The question is what AVX actually means: To me it's an instruction set
>> extension, not one of machine state. The machine state extension to
>> me is tied to XSAVE (or more precisely to XSAVE's YMM state). (But I
>> intentionally say "to me", because I can certainly see why this may be
>> viewed differently.)
> 
> The AVX feature bit is also the indicator that the AVX bit may be set in
> XCR0, which links it to machine state and not just instruction sets.

No, it's not (and again - there's no bit named AVX in XCR0): Which
bits can be set in XCR0 is enumerated by CPUID[0xd].EDX:EAX,
which is - surprise, surprise - the so called XSTATE leaf (i.e. related
to XSAVE, and not to AVX).

>>  Note how you yourself have recourse to XCR0,
>> which is very clearly tied to XSAVE and not AVX, above (and note also
>> that there's nothing called AVX to be enabled in XCR0, it's YMM that
>> you talk about).
> 
> The key point is this.  If I choose to enable XSAVE and disable AVX for
> a domain, that domain is unable to FMA/FMA4/F16C instructions.  It
> therefore shouldn't see the features.

Are you sure? Did you try? Those instructions may not be very
useful without other AVX instructions, but I don't think there's
any coupling. And if I, as an example, look at one of the
3-operand vfmadd instructions, I also don't see any #UD
resulting from the AVX bit being clear (as opposed to various of
the AVX-512 extensions, which clearly document that AVX512F
needs to always be checked). It's only in the textual description
of e.g. FMA or AVX2 detection where such a connection is being
made.

In any event, please don't misunderstand my bringing up of this
as objection to the way you handle things. I merely wanted to
point out again that this is not the only way the (often self-
contradictory) SDM can be understood.

Jan


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