From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/PV: hide features dependent on XSAVE
 when booted with "no-xsave"
Date: Mon, 30 Nov 2015 11:10:39 +0000
Message-ID: <565C2EAF.7000003@citrix.com>
References: <5658471802000078000B9A27@prv-mh.provo.novell.com>
	<56587149.6010909@citrix.com>
	<565C2C8502000078000BA18C@prv-mh.provo.novell.com>
	<565C28FE.80205@citrix.com>
	<565C3C2E02000078000BA250@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=769e600f3=Andrew.Cooper3@citrix.com>)
	id 1a3MM0-0004Pv-AT
	for xen-devel@lists.xenproject.org; Mon, 30 Nov 2015 11:10:44 +0000
In-Reply-To: <565C3C2E02000078000BA250@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 30/11/15 11:08, Jan Beulich wrote:
>>>> On 30.11.15 at 11:46, <andrew.cooper3@citrix.com> wrote:
>> On 30/11/15 10:01, Jan Beulich wrote:
>>>>>> On 27.11.15 at 16:05, <andrew.cooper3@citrix.com> 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@suse.com>
>>>> 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