• Konrad Rzeszutek Wilk's avatar
    xen/acpi-processor: C and P-state driver that uploads said data to hypervisor. · 59a56802
    Konrad Rzeszutek Wilk authored
    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 <pasik@iki.fi>]
    [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 <jbeulich@suse.com> 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: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    59a56802
Kconfig 6.87 KB