|
[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 |