From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: [PATCH] ACPI: Add fixups for AMD P-state figures. Date: Wed, 06 Mar 2013 10:48:01 +0100 Message-ID: <513710D1.2010803@canonical.com> References: <1362512728-28770-1-git-send-email-konrad.wilk@oracle.com> <51365401.4050205@oracle.com> <20130305213319.GA8235@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2939946960536664170==" Return-path: In-Reply-To: <20130305213319.GA8235@phenom.dumpdata.com> 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: Boris Ostrovsky , xen-devel@lists.xensource.com, bp@suse.de List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2939946960536664170== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6ACD95997F390B1E59802892" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6ACD95997F390B1E59802892 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.03.2013 22:33, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 05, 2013 at 03:22:25PM -0500, Boris Ostrovsky wrote: >> On 03/05/2013 02:45 PM, Konrad Rzeszutek Wilk wrote: >>> This a copy-n-paste from two Linux git commits: >>> >>> - f594065faf4f9067c2283a34619fc0714e79a98d >>> ACPI: Add fixups for AMD P-state figures >>> - 9855d8ce41a7801548a05d844db2f46c3e810166 >>> ACPI: Check MSR valid bit before using P-state frequencies >>> >>> The issue is that "some AMD systems may round the frequencies in >>> ACPI tables to 100MHz boundaries. We canobtain the real >>> frequencies from MSRs, so add a quirk to fix these frequencies up >>> on AMD systems." (from f594065..) >>> >>> In discussion (around 9855d8..) "it turned out that indeed real >>> HW/BIOSes may choose to not set the valid bit and thus mark the >>> P-state as invalid. So this could be considered a fix for broken >>> BIOSes that also works around the issue on Xen." (from 9855d8..) >>> >>> I've tested it under Dell Inc. PowerEdge T105 /0RR825, BIOS 1.3.2 >>> 08/20/2008 where this quirk can indeed be observed. >>> >>> CC: stefan.bader@canonical.com >>> CC: bp@suse.de >>> CC: borislav.ostrovsky@oracle.com >> >> boris.ostrovsky@oracle.com >=20 > Whoops! >=20 > Here is an updated version: >=20 > From 3b7584f0c3c91d073bd760a038d0091b3bf5a19b Mon Sep 17 00:00:00 2001 > From: Konrad Rzeszutek Wilk > Date: Tue, 5 Mar 2013 14:40:52 -0500 > Subject: [PATCH] ACPI: Add fixups for AMD P-state figures. >=20 > This a copy-n-paste from two Linux git commits: >=20 > - f594065faf4f9067c2283a34619fc0714e79a98d > ACPI: Add fixups for AMD P-state figures > - 9855d8ce41a7801548a05d844db2f46c3e810166 > ACPI: Check MSR valid bit before using P-state frequencies >=20 > The issue is that "some AMD systems may round the frequencies in > ACPI tables to 100MHz boundaries. We canobtain the real > frequencies from MSRs, so add a quirk to fix these frequencies up > on AMD systems." (from f594065..) >=20 > In discussion (around 9855d8..) "it turned out that indeed real > HW/BIOSes may choose to not set the valid bit and thus mark the > P-state as invalid. So this could be considered a fix for broken > BIOSes that also works around the issue on Xen." (from 9855d8..) Boris and Jan already pointed out more than I would have spotted. So it s= eems the only thing left is the commit description. Well maybe it is just my w= ay of reading it but it feels like here the actual description/argument is miss= ing. I think it might be that Xen gets the unmodified values from the ACPI par= sing in dom0 because it cannot/does not want to allow dom0 to read the MSR. Instead this patch will cause the frequencies to be adapted in the hyperv= isor. -Stefan >=20 > I've tested it under Dell Inc. PowerEdge T105 /0RR825, BIOS 1.3.2 > 08/20/2008 where this quirk can indeed be observed. >=20 > CC: stefan.bader@canonical.com > CC: bp@suse.de > CC: boris.ostrovsky@oracle.com > [v1: Indent, #define, and email changes per Boris's review] > Signed-off-by: Konrad Rzeszutek Wilk > --- > xen/arch/x86/acpi/cpufreq/powernow.c | 38 ++++++++++++++++++++++++++++= ++++++++ > 1 file changed, 38 insertions(+) >=20 > diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/c= pufreq/powernow.c > index a9b7792..5037c30 100644 > --- a/xen/arch/x86/acpi/cpufreq/powernow.c > +++ b/xen/arch/x86/acpi/cpufreq/powernow.c > @@ -147,6 +147,42 @@ static int powernow_cpufreq_target(struct cpufreq_= policy *policy, > return 0; > } > =20 > +static void amd_fixup_frequency(struct xen_processor_px *px) > +{ > + u32 hi, lo, fid, did; > + int index =3D px->control & 0x00000007; > + > + if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_AMD) > + return; > + > + if ((boot_cpu_data.x86 =3D=3D 0x10 && boot_cpu_data.x86_model < 10) > + || boot_cpu_data.x86 =3D=3D 0x11) { > + rdmsr(MSR_PSTATE_DEF_BASE + index, lo, hi); > + /* > + * MSR C001_0064+: > + * Bit 63: PstateEn. Read-write. If set, the P-state is valid.= > + */ > + if (!(hi & (1UL << 31))) > + return; > + > + fid =3D lo & 0x3f; > + did =3D (lo >> 6) & 7; > + if (boot_cpu_data.x86 =3D=3D 0x10) > + px->core_frequency =3D (100 * (fid + 0x10)) >> did; > + else > + px->core_frequency =3D (100 * (fid + 8)) >> did; > + } > +} > + > +static void amd_fixup_freq(struct processor_performance *perf) > +{ > + > + int i; > + > + for (i =3D 0; i < perf->state_count; i++) > + amd_fixup_frequency(&perf->states[i]); > + > +} > static int powernow_cpufreq_verify(struct cpufreq_policy *policy) > { > struct acpi_cpufreq_data *data; > @@ -253,6 +289,8 @@ static int powernow_cpufreq_cpu_init(struct cpufreq= _policy *policy) > =20 > policy->governor =3D cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVE= RNOR; > =20 > + amd_fixup_freq(perf); > + > /* table init */ > for (i =3D 0; i < perf->state_count && i <=3D max_hw_pstate; i++) = { > if (i > 0 && perf->states[i].core_frequency >=3D >=20 --------------enig6ACD95997F390B1E59802892 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRNxDZAAoJEOhnXe7L7s6jP8sP+wZb6yvvRkI10wtwfJ6O7Ajs o1fh4x64lngZopxP/Dc8h9XK78hAz07bI+UkJs8jt31AiXg0lbrT+1ShOzjU0dqR qjfZiiA1irPrfDJaVugOTTy9EKND4y2giOePbK46ZTh7Tmw7yuLoDFvbF04jNQaN fzabMB9G2KjOb5xvhVtVyZYneUhVh1cntW8nK8Z6bRt2vEOFHK3EMDY+CDY6mu53 9cRv1qlgiTCpmR7++EvwmtW7WcWJ3tCEYy9Q/NeLbpaygemWXAs3+xnojyVaee5L 0WPsj1KwJ5ZB7eYL2Zv8FtMF0zBLAi9OeayqwOWZMIW8k4Afm5IwyLegvBsbiizE 1XPvwnJhx78f0JUh+eEP5aLRL0oxypz4Mg6PrZFDacwoDLEdCQ2B7gHIgeXAwxz9 O5mSUxfRlmQ/6tbhRcnTCNF2iYKEbxJumw/H93X+3++hWAsi/uqoCNUQAHXJ0Bjk mMFGo4yIyhnP2z2CFti/2TI3RQzfmxG/AOAnfRr1F/R5TtNXeRBrRZOAaQ8BLLXe s63dSABCQdedjH5tUV+M9m5ARHUlrTzKD2z9f5fFr+0B9zHfcyLcCq92RT1uYGcB aPo2FyLr1jPUmmpDb6MWaJJyjmLX4afprLNFssZnI9+DH2obMH0befbJp04/SLCg v37gk4SNcZ7jfnzzOPB4 =B+Pd -----END PGP SIGNATURE----- --------------enig6ACD95997F390B1E59802892-- --===============2939946960536664170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2939946960536664170==--