[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH] pmstat: Limit hypercalls under HWP
When HWP is active, the cpufreq P-state information is not updated. In that case, return -ENODEV instead of bogus, incomplete info. The xenpm command already supports skipping results when -ENODEV is returned, so it is re-used when -EOPNOTSUPP might be more accurate. Similarly, set_cpufreq_para() is not applicable when HWP is active. Many of the options already checked the governor and were inaccessible, but SCALING_MIN/MAX_FREQ was still accessible (though it would do nothing). Add an ealier HWP check to handle all cases. Signed-off-by: Jason Andryuk <jandryuk@xxxxxxxxx> --- `xenpm get-cpufreq-states` now doesn't return any output. It also exits successfully since xenpm doesn't check the returns there. Other commands will fail: xenpm set-scaling-maxfreq 11 1100000 failed to set scaling max freq (95 - Operation not supported) xen/drivers/acpi/pmstat.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c index 85097d463c..4c4d298d1c 100644 --- a/xen/drivers/acpi/pmstat.c +++ b/xen/drivers/acpi/pmstat.c @@ -66,6 +66,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op) return -ENODEV; if ( !cpufreq_driver.init ) return -ENODEV; + if ( hwp_active() ) + return -ENODEV; if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) ) return -EINVAL; break; @@ -329,6 +331,9 @@ static int set_cpufreq_para(struct xen_sysctl_pm_op *op) if ( !policy || !policy->governor ) return -EINVAL; + if ( hwp_active() ) + return -EOPNOTSUPP; + switch(op->u.set_para.ctrl_type) { case SCALING_MAX_FREQ: -- 2.43.0
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |