Re: Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 02/17/2016 02:02 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 15, 2016 at 03:41:41PM +0000, Andrew Cooper wrote:
>> On 15/02/16 15:02, Jan Beulich wrote:
>>>>>> On 15.02.16 at 15:53, <andrew.cooper3@citrix.com> wrote:
>>>> 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.
>>> Hmm, you're right, somehow I've managed to ignore the relevant
>>> lines grep reported. Yet - how do things work then, without the
>>> MWAIT feature flag currently getting cleared?


We whitelist CPUID0x00000001.ecx features in 
libxc/xc_cpuid_x86.c:xc_cpuid_hvm_policy() so MWAIT is never set.

-boris


>> I have never observed it being used.  Do you have some local patches in
>> the SLES hypervisor?
>>
>> There is some gross layer violation in xen/enlighten.c to pretend that
>> MWAIT is present to trick the ACPI code into evaluating _CST() methods
>> to report back to Xen.  (This is yet another PV-ism which will cause a
>> headache for a DMLite dom0)
> Yes indeed. CC-ing Roger, and Boris.
>
>> ~Andrew
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel