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

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

. snip..
> >>>>> 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.
> 
> Hm, I've took a look at the ACPI tables in one of my systems, and I'm 
... snip ..
> Do we have a formal list of what exactly does Xen want from ACPI that 
> it cannot fetch itself?
> 
> I'm quite sure Xen cares about all the "Processor Vendor-Specific ACPI" 
> [0], that should be _PCT, _CST and _PTC (located in \_PR_.CPUN._XXX).

Correct. But those values - especially _CST are modified by the firmware
depending on the ..[something, I can't actually find the code for it].

Here is an copy-n-paste of the code that sets the
generic ACPI code on the path to get the lower C-states:

commit 73c154c60be106b47f15d1111fc2d75cc7a436f2
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:   Mon Feb 13 22:26:32 2012 -0500

    xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
    
    For the hypervisor to take advantage of the MWAIT support it needs
    to extract from the ACPI _CST the register address. But the
    hypervisor does not have the support to parse DSDT so it relies on
    the initial domain (dom0) to parse the ACPI Power Management information
    and push it up to the hypervisor. The pushing of the data is done
    by the processor_harveset_xen module which parses the information that
    the ACPI parser has graciously exposed in 'struct acpi_processor'.
    
    For the ACPI parser to also expose the Cx states for MWAIT, we need
    to expose the MWAIT capability (leaf 1). Furthermore we also need to
    expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
    function.
    
    The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
    operations, but it can't do it since it needs to be backwards compatible.
    Instead we choose to use the native CPUID to figure out if the MWAIT
    capability exists and use the XEN_SET_PDC query hypercall to figure out
    if the hypervisor wants us to expose the MWAIT_LEAF capability or not.
    
    Note: The XEN_SET_PDC query was implemented in c/s 23783:
    "ACPI: add _PDC input override mechanism".
    
    With this in place, instead of
     C3 ACPI IOPORT 415
    we get now
     C3:ACPI FFH INTEL MWAIT 0x20
    
    Note: The cpu_idle which would be calling the mwait variants for
idling
    never gets set b/c we set the default pm_idle to be the hypercall
variant.

> 
> Roger.
> 
> [0] 
> http://www.intel.es/content/dam/www/public/us/en/documents/product-specifications/processor-vendor-specific-acpi-specification.pdf

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