Re: [Xen-devel] [PATCH] x86/PV: hide features dependent on XSAVE when booted with "no-xsave"

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 30/11/15 11:30, Jan Beulich wrote:
>>>> On 30.11.15 at 12:10, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 30/11/15 11:08, Jan Beulich wrote:
>>>>>> On 30.11.15 at 11:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 30/11/15 10:01, Jan Beulich wrote:
>>>>>>>> On 27.11.15 at 16:05, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>> On 27/11/15 11:05, Jan Beulich wrote:
>>>>>>> ... or when the guest has the XSAVE feature hidden by CPUID policy.
>>>>>>> Not doing so is at best confusing to guests.
>>>>>>>
>>>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>> These changes here are an improvement (so I don't object to taking them
>>>>>> ahead of my fullblown levelling series), but they are incomplete.
>>>>>>
>>>>>> xsaveopt, xsavec, xsetbv1, xsaves, avx and mpx depend on xsave.
>>>>>> fma, fma4, f16c, avx2 and xop depend on avx.
>>>>> I think the dependencies here are a little fuzzy, and hence I'd
>>>>> prefer us to not enforce more strict rules than are truly necessary:
>>>>>
>>>>> FMA: Neither Intel's SDM nor AMD's PM state any dependency on AVX.
>>>>>
>>>>> FMA4, XOP: AMD's PM doesn't state any dependency on AVX.
>>>>>
>>>>> AVX2: While Intel's SDM doesn't say so here either, I agree in this case.
>>>>>
>>>>> I.e. my view is that FMA{,4} and XOP are all pretty much
>>>>> independent of AVX, and they e.g. imply by themselves presence of
>>>>> YMM registers.
>>>> The AVX feature means several things, and in this case support for VEX
>>>> encoded instructions.
>>> Yet I don't think "VEX encoding" == "AVX". See the various VEX-
>>> encoded non-SIMD instructions.
>>>
>>>> Per SDM Vol 2, Table 2-18, any VEX encoded instruction will
>>>> unconditionally #UD fault if XCR0[2:1] != '11b' or CR0.OSXSAVE = 0.
>>> I.e. a dependency on XSAVE, but not on AVX.
>> XCR0[2:1] are the AVX and SSE bits.
> You mean the YMM and XMM ones (the latter one is  mis-named in
> our code base).

True - I will put it on my TODO list when making XSAVE state safe for
migration (which requires other changes in this area).

> It's not well defined whether YMM register presence
> correlates to AVX, or is simply flagged by the respective XSTATE
> CPUID bit (or a mixture of both).

It is indeed not well defined, which is what makes this area of
functionality so hard to level safely.

> The minimal (and imo more natural) dependency is just the XSTATE bit.

But it is wrong.

Any VEX encoded SIMD operation unconditionally works on YMM state.  In
the case that XMM registers are encoded with a VEX prefix, the upper 128
bits of the YMM register are zeroed (SDM Vol 2, 2.3.10).  This is
contrary to legacy SSE instructions which preserve the upper 128 bits.

Therefore, FMA, FMA4 and XOP do have a strict dependency on AVX.

~Andrew

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