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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

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).

Roger.


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