From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability
 in featureset
Date: Mon, 15 Feb 2016 14:53:45 +0000
Message-ID: <56C1E679.7060405@citrix.com>
References: <1454679743-18133-1-git-send-email-andrew.cooper3@citrix.com>
	<1454679743-18133-11-git-send-email-andrew.cooper3@citrix.com>
	<56BE1EEB02000078000D1896@prv-mh.provo.novell.com>
	<56BE198A.2000408@citrix.com>
	<56C1A66302000078000D1F8C@prv-mh.provo.novell.com>
	<56C1E2FA.2020701@citrix.com>
	<56C1F3B002000078000D22D6@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>
In-Reply-To: <56C1F3B002000078000D22D6@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.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 15/02/16 14:50, Jan Beulich wrote:
>>>> On 15.02.16 at 15:38, <andrew.cooper3@citrix.com> wrote:
>> On 15/02/16 09:20, Jan Beulich wrote:
>>>>>> On 12.02.16 at 18:42, <andrew.cooper3@citrix.com> wrote:
>>>> On 12/02/16 17:05, Jan Beulich wrote:
>>>>>>>> On 05.02.16 at 14:42, <andrew.cooper3@citrix.com> wrote:
>>>>>>  #define X86_FEATURE_MWAITX        ( 3*32+29) /*   MWAIT extension 
>>>> (MONITORX/MWAITX) */
>>>>> Why not exposed to HVM (also for _MWAIT as I now notice)?
>>>> Because that is a good chunk of extra work to support.  We would need to
>>>> use 4K monitor widths, and extra p2m handling.
>>> I don't understand: The base (_MWAIT) feature being exposed to
>>> guests today, and kernels making use of the feature when available
>>> suggests to me that things work. Are you saying you know
>>> otherwise? (And if there really is a reason to mask the feature all of
>>> the sudden, this should again be justified in the commit message.)
>> PV guests had it clobbered by Xen in traps.c
>>
>> HVM guests have:
>>
>> vmx.c:
>>     case EXIT_REASON_MWAIT_INSTRUCTION:
>>     case EXIT_REASON_MONITOR_INSTRUCTION:
>> [...]
>>     hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
>>         break;
>>
>> and svm.c:
>>     case VMEXIT_MONITOR:
>>     case VMEXIT_MWAIT:
>>         hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
>>         break;
>>
>> I don't see how a guest could actually use this feature.
> Do you see the respective intercepts getting enabled anywhere?
> (I don't outside of nested code, which I didn't check in detail.)

Yes - the intercepts are always enabled to prevent the guest actually
putting the processor to sleep.

~Andrew