Messages in this thread | | | Date | Mon, 27 Feb 2012 08:19:24 +0000 | From | "Jan Beulich" <> | Subject | Re: [PATCH] processor passthru - upload _Cx and _Pxx data to hypervisor (v5). |
| |
>>> On 25.02.12 at 01:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > But cpufreq != cpuidle != cpufreq governor, and they all are run by > different rules. > The ondemand cpufreq governor for example runs a timer and calls the > appropiate cpufreq > driver. So with these patches I posted we end up with a cpufreq driver in > the kernel > and in Xen hypervisor - both of them trying to change Pstates. Not good (to > be fair, > if powernow-k8/acpi-cpufreq would try it via WRMSR - those would up being > trapped and > ignored by the hypervisor. I am not sure about the outw though).
I'm not aware of any trapping that would be done on the I/O port here; it could be added, though (i.e. the ports removed from the list of allowed ports of Dom0 once they become known to the hypervisor).
> The pre-RFC version of this posted driver implemented a cpufreq governor that > was > nop and for future work was going to make a hypercall to get the true > cpufreq value > to report properly in /proc/cpuinfo - but I hadn't figured out a way to make > it be > the default one dynamically. > > Perhaps having xencommons do > echo "xen" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > > And s/processor-passthru/cpufreq-xen/ would do it? That would eliminate the > [performance, > ondemand,powersave,etc] cpufreq governors from calling into the cpufreq > drivers to alter P-states.
Except that you want this to be a cpufreq driver, not a governor.
Jan
| |