[Xen-devel] expose MWAIT to dom0

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

There're basically two methods to enter a given C-state: legacy (hlt + I/O 
read),
and native(using mwait). MWAIT is always preferred when both underlying CPU
and OS support, which is a more efficient way to conduct C-state transition.

Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves one
step to notify BIOS about a set of capabilities supported by OSPM. One 
capability
is about mwait support, which if true ACPI Cx entry contains entry parameters 
for mwait, or else I/O port information is provided. Xen PM later decides entry
method (i/o or mwait) based on parsed ACPI information from dom0.

However Xen doesn't expose MWAIT capability to dom0 due to changeset 17573:

# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1210065934 -3600
# Node ID 777f294e3be81a4d0825e3a9b633a8d81c37f613
# Parent  d5589865bfce91bf65c34bd56e466bf26ca4176f
x86, Intel: Make only EST feature visible to dom0 to enable Cx-state
logic. There should be no need to make MWAIT visible.
Signed-off-by: Keir Fraser <keir.fraser@xxxxxxxxxx>
diff -r d5589865bfce -r 777f294e3be8 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c      Tue May 06 10:19:10 2008 +0100
+++ b/xen/arch/x86/traps.c      Tue May 06 10:25:34 2008 +0100
@@ -713,8 +713,7 @@ static int emulate_forced_invalid_op(str
         __clear_bit(X86_FEATURE_PBE, &d);
 
         __clear_bit(X86_FEATURE_DTES64 % 32, &c);
-        if ( !IS_PRIV(current->domain) )
-            __clear_bit(X86_FEATURE_MWAIT % 32, &c);
+        __clear_bit(X86_FEATURE_MWAIT % 32, &c);
         __clear_bit(X86_FEATURE_DSCPL % 32, &c);
         __clear_bit(X86_FEATURE_VMXE % 32, &c);
         __clear_bit(X86_FEATURE_SMXE % 32, &c);
[...]

This then brings a problem to Dom0 which thinks underlying CPU
doesn't report mwait, and thus notify BIOS to use old I/O based method.

Later a trick is integrated in Jeremy's pvops tree:

commit 4151815a222723002d727ef0a89f0756d4e7d3d2
Author: Wei Gang <gang.wei@xxxxxxxxx>
Date:   Mon Apr 5 14:21:18 2010 -0700

    xen/acpi: re-enable mwait for xen cpuidle
    
    Xen hypervisor doesn't export mwait feature to dom0, but latest Linux
    kernel start to check this feature while initializing _PDC
    object. Bypass such check in pv-ops case to re-enable mwait for xen
    cpuidle.
    
    Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
    Signed-off-by: Yu Ke <ke.yu@xxxxxxxxx>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>

diff --git a/arch/x86/kernel/acpi/processor.c b/arch/x86/kernel/acpi/processor.c
index 8c9526d..d88866c 100644
--- a/arch/x86/kernel/acpi/processor.c
+++ b/arch/x86/kernel/acpi/processor.c
@@ -60,7 +60,7 @@ static void init_intel_pdc(struct acpi_processor *pr, struct 
cpuinfo_x86 *c)
        /*
         * If mwait/monitor is unsupported, C2/C3_FFH will be disabled
         */
-       if (!cpu_has(c, X86_FEATURE_MWAIT))
+       if (!cpu_has(c, X86_FEATURE_MWAIT) && !xen_initial_domain())
                buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
 
        obj->type = ACPI_TYPE_BUFFER;

Above trick is ugly and error-prone, since it always enable mwait regardless of
actual CPU capability. It's unlikely to make into upstream, and also get lost in
into some distro such as SLES11.

Instead of enhancing current approach (e.g. add a separate channel to reveal
mwait capability instead of using cpuid), I'm curious why we don't expose mwait
in cpuid to dom0 directly. At least original comment in 17573 looks obscure, 
since EIST has nothing to do with Cx...

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel