[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/18/2016 10:12 AM, Andrew Cooper wrote:
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.

We will have to come up with something else: AIUI the whole point of xen_check_mwait() is to come up with proper ECX and EDX values for the MWAIT CPUID leaf. Those value are expected to be reported from xen_cpuid() pv_op so that acpi_processor_ffh_state_probe_cpu() can set C states structures properly.

The problem is that PVH executes CPUID instruction natively. (And so this must have been broken on PVHv1 as well).

-boris



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


 


Rackspace

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