[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] kernel 3.7+ cpufreq regression on AMD system running as dom0



On 01/16/2013 11:26 AM, Jan Beulich wrote:
On 15.01.13 at 18:53, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
On Mon, Jan 14, 2013 at 05:34:45PM +0100, Borislav Petkov wrote:
On Mon, Jan 14, 2013 at 04:58:54PM +0100, Stefan Bader wrote:
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -340,6 +340,9 @@ static void amd_fixup_frequency(struct acpi_processor_px *px
         if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10)
             || boot_cpu_data.x86 == 0x11) {
                 rdmsr(MSR_AMD_PSTATE_DEF_BASE + index, lo, hi);
+               /* Bit 63 indicates whether contents are valid */
+               if (!(hi & 0x8000000))
+                       return;

I don't think that's the right change - this is fixing baremetal so that
it works on xen. And besides, this code was in powernow-k8 before so I'm
wondering why did it work then.

Powernow-k8 only populated the cpufreq policy information. This library
(processor_perflib) is the generic library used for ACPI P-states parsing.
This specific function (acpi_processor_get_performance_states) is just
used to fetch and parse the P-states.

Xen-acpi-processor (which we use to upload the P and C-states to the
hypervisor) ends up calling this library to parse the P-states
and this unfortunate quirk clamps the P-states based on the MSRS.

It is odd that this CPU specific quirk got added in this generic
library. Is there no ACPI quirk system similar to how DMI quirks
are handled?

Anyhow, I think this patch makes sense - it makes sure that the
MSR value is sane.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

Did someone actually _test_ that patch? I ask because the mask
used (0x8000000) doesn't check bit 63 as the comment says, but
bit 59 instead...

Jan

Not this version which I did at the end of a day to have a cleaned up version to discuss. And obviously I managed to get the number of zeros wrong. :(

The comment is right and it should be 0x80000000

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.