Re: [Xen-devel] 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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/02/16 15:02, Roger Pau Monné wrote:
> El 17/2/16 a les 20:02, Konrad Rzeszutek Wilk ha escrit:
>> 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@xxxxxxxxxx> wrote:
>>>>> On 15/02/16 14:50, Jan Beulich wrote:
>>>>>>>>> On 15.02.16 at 15:38, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>>> On 15/02/16 09:20, Jan Beulich wrote:
>>>>>>>>>>> On 12.02.16 at 18:42, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>>>>> On 12/02/16 17:05, Jan Beulich wrote:
>>>>>>>>>>>>> On 05.02.16 at 14:42, <andrew.cooper3@xxxxxxxxxx> 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?
>>> 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.
> Yes, all this is indeed not very nice, and we would ideally like to get
> rid of it on PVHv2.
>
> Could we use the acpica tools (acpidump/acpixtract/acpiexec/...) in
> order to fetch this information from user-space and send it to Xen using
> privcmd?
>
> AFAIK those tools work on most OSes (or at least the ones we care about
> as Dom0).

In general, we can't rely on userspace evaluation of AML.

For trivial AML which evaluates to a constant, it could be interpreted
by userspace, but anything accessing system resources will need
evaluating by the kernel.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel