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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50F6BA8C.1070709@canonical.com>
Date:	Wed, 16 Jan 2013 15:34:52 +0100
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Jan Beulich <JBeulich@...e.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Borislav Petkov <bp@...en8.de>,
	Andre Przywara <andre@...rep.de>,
	xen-devel <xen-devel@...ts.xen.org>,
	Matthew Garrett <mjg@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: 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@...cle.com> 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@...cle.com>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/