[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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@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
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:

     hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);

and svm.c:
     case VMEXIT_MWAIT:
         hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);

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.


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.


Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.