From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: [RFC PATCH] THERM_CONTROL_MSR mucks with Xen cpufreq code. Date: Fri, 18 Dec 2015 15:46:45 -0500 Message-ID: <1450471606-19129-1-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aA1vZ-0002FJ-EP for xen-devel@lists.xenproject.org; Fri, 18 Dec 2015 20:47:01 +0000 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: gang.wei@intel.com, JBeulich@suse.com, xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, ian.campbell@citrix.com, keir@xen.org, tim@xen.org List-Id: xen-devel@lists.xenproject.org Hey, I've gotten feedback from some of the internal BIOS folks who had noticied some issues (the machine is running very slowly) which we found out was due to the ACPI DSDT being busted and the Linux kernel (dom0) programming the _wrong_ values in the T-state MSR. While this got fixed in the BIOS - it occurred to me that we really shouldn't let dom0 poke at this MSR? The patch that added this functionality didn't have much details.