[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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.

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

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