20 Jul, 2012

1 commit

  • This patch provide Xen physical cpus online/offline sys interface.
    User can use it for their own purpose, like power saving:
    by offlining some cpus when light workload it save power greatly.

    Its basic workflow is, user online/offline cpu via sys interface,
    then hypercall xen to implement, after done xen inject virq back to dom0,
    and then dom0 sync cpu status.

    Signed-off-by: Jiang, Yunhong
    Signed-off-by: Liu, Jinsong
    Signed-off-by: Konrad Rzeszutek Wilk

    Liu, Jinsong
     

15 Mar, 2012

1 commit

  • This driver solves three problems:
    1). Parse and upload ACPI0007 (or PROCESSOR_TYPE) information to the
    hypervisor - aka P-states (cpufreq data).
    2). Upload the the Cx state information (cpuidle data).
    3). Inhibit CPU frequency scaling drivers from loading.

    The reason for wanting to solve 1) and 2) is such that the Xen hypervisor
    is the only one that knows the CPU usage of different guests and can
    make the proper decision of when to put CPUs and packages in proper states.
    Unfortunately the hypervisor has no support to parse ACPI DSDT tables, hence it
    needs help from the initial domain to provide this information. The reason
    for 3) is that we do not want the initial domain to change P-states while the
    hypervisor is doing it as well - it causes rather some funny cases of P-states
    transitions.

    For this to work, the driver parses the Power Management data and uploads said
    information to the Xen hypervisor. It also calls acpi_processor_notify_smm()
    to inhibit the other CPU frequency scaling drivers from being loaded.

    Everything revolves around the 'struct acpi_processor' structure which
    gets updated during the bootup cycle in different stages. At the startup, when
    the ACPI parser starts, the C-state information is processed (processor_idle)
    and saved in said structure as 'power' element. Later on, the CPU frequency
    scaling driver (powernow-k8 or acpi_cpufreq), would call the the
    acpi_processor_* (processor_perflib functions) to parse P-states information
    and populate in the said structure the 'performance' element.

    Since we do not want the CPU frequency scaling drivers from loading
    we have to call the acpi_processor_* functions to parse the P-states and
    call "acpi_processor_notify_smm" to stop them from loading.

    There is also one oddity in this driver which is that under Xen, the
    physical online CPU count can be different from the virtual online CPU count.
    Meaning that the macros 'for_[online|possible]_cpu' would process only
    up to virtual online CPU count. We on the other hand want to process
    the full amount of physical CPUs. For that, the driver checks if the ACPI IDs
    count is different from the APIC ID count - which can happen if the user
    choose to use dom0_max_vcpu argument. In such a case a backup of the PM
    structure is used and uploaded to the hypervisor.

    [v1-v2: Initial RFC implementations that were posted]
    [v3: Changed the name to passthru suggested by Pasi Kärkkäinen ]
    [v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
    [v5: Cleaned up the driver, fix bug under Athlon XP]
    [v6: Changed the driver to a CPU frequency governor]
    [v7: Jan Beulich suggestion to make it a cpufreq scaling driver
    made me rework it as driver that inhibits cpufreq scaling driver]
    [v8: Per Jan's review comments, fixed up the driver]
    [v9: Allow to continue even if acpi_processor_preregister_perf.. fails]
    Signed-off-by: Konrad Rzeszutek Wilk

    Konrad Rzeszutek Wilk
     

11 Mar, 2012

1 commit

  • 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.

    Acked-by: Jan Beulich
    [v2: Fix missing header file include and #ifdef]
    Signed-off-by: Konrad Rzeszutek Wilk

    Konrad Rzeszutek Wilk
     

27 Sep, 2011

1 commit

  • This patches implements the xen_platform_op hypercall, to pass the parsed
    ACPI info to hypervisor.

    Signed-off-by: Yu Ke
    Signed-off-by: Tian Kevin
    Signed-off-by: Jeremy Fitzhardinge
    [v1: Added DEFINE_GUEST.. in appropiate headers]
    [v2: Ripped out typedefs]
    Signed-off-by: Konrad Rzeszutek Wilk

    Yu Ke