From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
To: Jan Beulich <JBeulich@suse.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>,
Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com,
Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: Fwd: [PATCH RFC 3/4] x86/AMD: support further feature masking MSRs
Date: Fri, 4 Apr 2014 11:21:53 -0500 [thread overview]
Message-ID: <533EDC21.8070603@amd.com> (raw)
In-Reply-To: <533E9975020000780000590E@nat28.tlf.novell.com>
On 4/4/2014 4:37 AM, Jan Beulich wrote:
>>>> On 04.04.14 at 00:44, <aravind.gopalakrishnan@amd.com> wrote:
>> On 4/1/2014 6:10 PM, Aravind Gopalakrishnan wrote:
>>>> Newer AMD CPUs also allow masking CPUID leaf 6 ECX and CPUID leaf 7
>>>> sub-leaf 0 EAX and EBX.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com
>>>> <mailto:jbeulich@suse.com>>
>>>>
>>>> TBD:
>>>> - Fam15M0x is documented to not have MSR C0011002 despite
>>>> CPUID[7,0].EBX != 0 from model 02
>>>> onwards, and contrary to what I see on the system I have access to
>>>> (which is model 02)
>>>> - Fam12, Fam14, and Fam16 are documented to not have MSR C0011003
>>>> despite CPUID[6].ECX != 0
>>> Fam10 too has cpuid[6].ecx != 0 but no MSR C0011003
>>>
>>>> - Fam11 is documented to not even have MSR C0011004 and C0011005
>>>>
>>> I am still trying to get some clarity on this;
>> Here's more info regarding your questions:
>> 1. This is a documentation error.
>> 2. We cannot mask cpuid[6].ecx on any of these families: 0x10, 0x11,
>> 0x12,0x14,0x16 as feature is not supported..
>> 3. We cannot mask standard,extended cpuid feature bits on Fam0x11 as
>> feature is not supported.
>>
>> So simple enough additions to your patch to include some family checks:
>>
>> + if (c->cpuid_level >= 7)
>> + cpuid_count(7, 0, &eax, &ebx, &ecx, &edx);
>> + else
>> + ebx = eax = 0;
>> + if ((eax | ebx) && ~(l7s0_eax & l7s0_ebx) &&
>> + c->x86 == 0x15 && c->x86_model >= 0x2) {
> Also, is Fam16 indeed not capable of masking features here too?
>
> Assuming "yes" and "no", I'd rather use
>
> if ((eax | ebx) && ~(l7s0_eax & l7s0_ebx) &&
> (c->x86 != 0x15 || c->x86_model >= 0x2)) {
>
> But then again models 0 and 1 are documented to have this CPUID
> leaf blank, so we shouldn't need a family/model check here at all.
Yes, you are right. No need for above family check at all.
But for fam16h, I was not able to access the MSR on my machine.
And here's why:
fam16h can use the MSR to mask the bit only if microcode patch level >=
0x700010a
While at it, I tried to clean up the issues you pointed above (and the
== 0x15 check below..).
Does this seem better? -
+ if (c->cpuid_level >= 7)
+ cpuid_count(7, 0, &eax, &ebx, &ecx, &edx);
+ else
+ ebx = eax = 0;
+
+ skip_l7s0_eax_ebx = skip_thermal_ecx = 1;
+ if ((eax | ebx) && ~(l7s0_eax & l7s0_ebx)) {
+ /* fam16h can mask l7s0 only if microcode lvl >= 0x700010a */
+ if (c->x86 == 0x16) {
+ uint32_t rev;
+ rdmsrl(MSR_AMD_PATCHLEVEL, rev);
+ if (rev < 0x700010a) {
+ printk("Cannot apply l7s0 mask as microcode patch lvl
is insufficient\n");
+ /*
+ * fam16h cannot mask MSR_AMD_THRM_FEATURE_MASK anyway
+ * so, fall through
+ */
+ goto setmask;
+ }
+ }
+ if (l7s0_eax > eax)
+ l7s0_eax = eax;
+ l7s0_ebx &= ebx;
+ skip_l7s0_eax_ebx = 0;
+ printk("Writing CPUID leaf 7 subleaf 0 feature mask EAX:EBX
-> %08Xh:%08Xh\n",
+ l7s0_eax, l7s0_ebx);
+ }
+ ecx = c->cpuid_level >= 6 ? cpuid_ecx(6) : 0;
+ /* MSR_AMD_THRM_FEATURE_MASK can be applied only on fam15h */
+ if (c->x86 != 0x15)
+ goto setmask;
+ if (ecx && ~thermal_ecx) {
+ thermal_ecx &= ecx;
+ skip_thermal_ecx = 0;
+ printk("Writing CPUID thermal/power feature mask ECX -> %08Xh\n",
+ thermal_ecx);
+ }
>> + if (l7s0_eax > eax)
>> + l7s0_eax = eax;
>> + l7s0_ebx &= ebx;
>> + printk("Writing CPUID leaf 7 subleaf 0 feature mask EAX:EBX -> %08Xh:%08Xh\n",
>> + l7s0_eax, l7s0_ebx);
>> + } else
>> + skip_l7s0_eax_ebx = 1;
>> + ecx = c->cpuid_level >= 6 ? cpuid_ecx(6) : 0;
>> + if (ecx && ~thermal_ecx && c->x86 == 0x15) {
> Will merge this, albeit I don't like == in checks like this at all.
>
>> + thermal_ecx &= ecx;
>> + printk("Writing CPUID thermal/power feature mask ECX -> %08Xh\n",
>> + thermal_ecx);
>> + } else
>> + skip_thermal_ecx = 1;
>> setmask:
>> - /* FIXME check if processor supports CPUID masking */
>> /* AMD processors prior to family 10h required a 32-bit password */
>> - if (c->x86 >= 0x10) {
>> + if (c->x86 >= 0x10 && c->x86 != 0x11) {
> I'll use this one, but in a separate prefix patch (as I'll want to backport
> this), and in a different fashion: I don't think the "else" path to this "if"
> applies to Fam11 either based on documentation and your statements
> above.
>
Yes, missed it. Sorry about that..
Thanks,
-Aravind
next prev parent reply other threads:[~2014-04-04 16:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <532880230200007800125450@nat28.tlf.novell.com>
2014-03-19 9:16 ` [PATCH RFC 0/4] x86/AMD: support newer hardware features Jan Beulich
2014-03-19 9:46 ` [PATCH RFC 1/4] x86/SVM: support data breakpoint extension registers Jan Beulich
2014-03-19 9:47 ` [PATCH RFC 2/4] x86/PV: " Jan Beulich
2014-03-19 9:47 ` [PATCH RFC 3/4] x86/AMD: support further feature masking MSRs Jan Beulich
[not found] ` <CAAAAutDJ3CzvGp9jWCS7=b3rQsG81+w_W7qXLKxDWB7QBU23DQ@mail.gmail.com>
2014-04-01 23:10 ` Fwd: " Aravind Gopalakrishnan
2014-04-03 22:44 ` Aravind Gopalakrishnan
2014-04-04 9:37 ` Jan Beulich
2014-04-04 16:21 ` Aravind Gopalakrishnan [this message]
2014-04-07 6:54 ` Jan Beulich
2014-04-07 8:52 ` Andrew Cooper
2014-04-07 9:14 ` Jan Beulich
2014-03-19 9:48 ` [PATCH RFC 4/4] x86/AMD: clean up pre-canned family/revision handling for CPUID masking Jan Beulich
2014-03-26 14:13 ` [PATCH v2 RFC 2/4] x86/PV: support data breakpoint extension registers Jan Beulich
2014-03-27 15:28 ` Ian Campbell
2014-03-27 16:03 ` Jan Beulich
2014-03-27 16:23 ` Ian Campbell
2014-03-27 16:44 ` Jan Beulich
2014-03-27 17:29 ` Ian Campbell
2014-03-28 8:05 ` Jan Beulich
2014-03-28 9:55 ` Ian Campbell
2014-03-28 10:43 ` Jan Beulich
2014-03-28 10:56 ` Ian Campbell
2014-03-27 16:03 ` Andrew Cooper
2014-03-27 16:37 ` Jan Beulich
2014-03-27 17:11 ` Andrew Cooper
2014-03-28 10:46 ` Jan Beulich
[not found] ` <CAAAAutAgdSJqYEjc4dtixuTS2S=PUx-L4Sy=JCQRZ57rTdoPCQ@mail.gmail.com>
2014-03-26 22:35 ` [PATCH RFC 0/4] x86/AMD: support newer hardware features Aravind Gopalakrishnan
2014-04-01 23:10 ` Aravind Gopalakrishnan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533EDC21.8070603@amd.com \
--to=aravind.gopalakrishnan@amd.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--cc=sherry.hurwitz@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).