From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 12/30] xen/x86: Generate deep dependencies of features Date: Mon, 15 Feb 2016 16:09:19 +0000 Message-ID: <56C1F82F.7000505@citrix.com> References: <1454679743-18133-1-git-send-email-andrew.cooper3@citrix.com> <1454679743-18133-13-git-send-email-andrew.cooper3@citrix.com> <56C1E96502000078000D225B@prv-mh.provo.novell.com> <56C1EEB9.5020206@citrix.com> <56C2025402000078000D23CE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56C2025402000078000D23CE@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org 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. > 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. ~Andrew