[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/PV: hide features dependent on XSAVE when booted with "no-xsave"
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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |