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

Reply via email to