From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Jones Subject: Re: Is: drivers/cpufreq/cpufreq-xen.c Was:Re: [PATCH 2 of 2] linux-xencommons: Load processor-passthru Date: Tue, 6 Mar 2012 12:59:48 -0500 Message-ID: <20120306175948.GA6656@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, Konrad Rzeszutek Wilk , stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Tue, Mar 06, 2012 at 12:40:08PM -0500, Konrad Rzeszutek Wilk wrote: > I think what you are suggesting is that to write a driver in drivers/cpufreq/ > that gets either started before the other ones (if built-in) or if as > a module gets > loaded from xencommons. That driver would then make the call > to acpi_processor_preregister_performance(), > acpi_processor_register_performance() and acpi_processor_notify_smm(). > It would function as a cpufreq-scaling driver but > in reality all calls to it from cpufreq gov-* drivers would end up with nop. > > Dave, would you be Ok with a driver like that in your tree? I joined this thread half-way through, so I'm not sure what the original problem was. How is a driver that does nothing better than just masking out the cpufreq capabilities to guests ? Dave