>>> On 18.12.15 at 22:31, <andrew.coop...@citrix.com> wrote: > On 18/12/2015 20:46, Konrad Rzeszutek Wilk wrote: >> Those two allow the OS pinned dom0 to change the T-state >> (throttling) behind the Xen cpufreq code. >> >> The patch that introduced this: f78e2193b6409577314167ed9e077de7ac3e652f >> >> x86: Enable THERM_CONTROL_MSR write for dom0 even when cpufreq=xen >> >> Signed-off-by: Wei Gang <gang....@intel.com> >> Signed-off-by: Keir Fraser <keir.fra...@citrix.com> >> >> is very lacking on details. >> >> Anyhow this patch in effect reverts the above commit. It is also >> lacking in details :-) >> >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > > We absolutely shouldn't let dom0 play with controls behind the back of a > driver in Xen.
Correct. Just that there still is no Tx state driver in Xen. > It would be nice if we can find out some of the reasoning behind this > change, but I am in principle for it. See above - the lack of a hypervisor side driver. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel