[Xen-devel] [PATCH] x86/cpuidle: correct Cannon Lake residency MSRs

[Xen-devel] [PATCH] x86/cpuidle: correct Cannon Lake residency MSRs

[Jan Beulich]

As per SDM rev 071 Cannon Lake has
- no CC3 residency MSR at 3FC,
- a CC1 residency MSR ar 660 (like various Atoms),
- a useless (always zero) CC3 residency MSR at 662.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Using the MSR cross reference in the same SDM revision one might even
get the impression that further MSRs are unavailable, but newer CPUs
don't appear to be consistently listed there at all, so may rather be a
doc shortcoming. I've pointed this out to Intel, but I'm not expecting
swift feedback.

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -68,7 +68,7 @@
 #define GET_PC8_RES(val)  GET_HW_RES_IN_NS(0x630, val) /* some Haswells only */
 #define GET_PC9_RES(val)  GET_HW_RES_IN_NS(0x631, val) /* some Haswells only */
 #define GET_PC10_RES(val) GET_HW_RES_IN_NS(0x632, val) /* some Haswells only */
-#define GET_CC1_RES(val)  GET_HW_RES_IN_NS(0x660, val) /* Silvermont only */
+#define GET_CC1_RES(val)  GET_HW_RES_IN_NS(0x660, val)
 #define GET_CC3_RES(val)  GET_HW_RES_IN_NS(0x3FC, val)
 #define GET_CC6_RES(val)  GET_HW_RES_IN_NS(0x3FD, val)
 #define GET_CC7_RES(val)  GET_HW_RES_IN_NS(0x3FE, val) /* SNB onwards */
@@ -179,8 +179,6 @@ static void do_get_hw_residencies(void *
     case 0x4E:
     case 0x55:
     case 0x5E:
-    /* Cannon Lake */
-    case 0x66:
     /* Kaby Lake */
     case 0x8E:
     case 0x9E:
@@ -202,6 +200,16 @@ static void do_get_hw_residencies(void *
         GET_CC3_RES(hw_res->cc3);
         GET_CC6_RES(hw_res->cc6);
         break;
+    /* Cannon Lake */
+    case 0x66:
+        GET_PC2_RES(hw_res->pc2);
+        GET_PC3_RES(hw_res->pc3);
+        GET_PC6_RES(hw_res->pc6);
+        GET_PC7_RES(hw_res->pc7);
+        GET_CC1_RES(hw_res->cc1);
+        GET_CC6_RES(hw_res->cc6);
+        GET_CC7_RES(hw_res->cc7);
+        break;
     /* Xeon Phi Knights Landing */
     case 0x57:
     /* Xeon Phi Knights Mill */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuidle: correct Cannon Lake residency MSRs

[Andrew Cooper]

On 14/11/2019 15:22, Jan Beulich wrote:
> As per SDM rev 071 Cannon Lake has
> - no CC3 residency MSR at 3FC,
> - a CC1 residency MSR ar 660 (like various Atoms),
> - a useless (always zero) CC3 residency MSR at 662.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Using the MSR cross reference in the same SDM revision one might even
> get the impression that further MSRs are unavailable, but newer CPUs
> don't appear to be consistently listed there at all, so may rather be a
> doc shortcoming. I've pointed this out to Intel, but I'm not expecting
> swift feedback.

We might consider dropping Cannon Lake.  It did ship 1 limited-release
parts, but only for laptop/tablet SKUs, and there is a reason why it has
been totally discontinued.

There is a very good chance that this is logic which will never be
exercised.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuidle: correct Cannon Lake residency MSRs

[Jan Beulich]

On 14.11.2019 20:28, Andrew Cooper wrote:
> On 14/11/2019 15:22, Jan Beulich wrote:
>> As per SDM rev 071 Cannon Lake has
>> - no CC3 residency MSR at 3FC,
>> - a CC1 residency MSR ar 660 (like various Atoms),
>> - a useless (always zero) CC3 residency MSR at 662.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Using the MSR cross reference in the same SDM revision one might even
>> get the impression that further MSRs are unavailable, but newer CPUs
>> don't appear to be consistently listed there at all, so may rather be a
>> doc shortcoming. I've pointed this out to Intel, but I'm not expecting
>> swift feedback.
> 
> We might consider dropping Cannon Lake.  It did ship 1 limited-release
> parts, but only for laptop/tablet SKUs, and there is a reason why it has
> been totally discontinued.

How would you envision "dropping" to look like: Do you mean just to
remove the case label here (and perhaps similar ones elsewhere), or
outright refuse booting on it?

In both cases if I were to submit such a change I'm afraid I'd want
to be a little less vague in the description than to just say "there
is a reason why it has been totally discontinued".

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuidle: correct Cannon Lake residency MSRs

[Andrew Cooper]

On 15/11/2019 09:37, Jan Beulich wrote:
> On 14.11.2019 20:28, Andrew Cooper wrote:
>> On 14/11/2019 15:22, Jan Beulich wrote:
>>> As per SDM rev 071 Cannon Lake has
>>> - no CC3 residency MSR at 3FC,
>>> - a CC1 residency MSR ar 660 (like various Atoms),
>>> - a useless (always zero) CC3 residency MSR at 662.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> Using the MSR cross reference in the same SDM revision one might even
>>> get the impression that further MSRs are unavailable, but newer CPUs
>>> don't appear to be consistently listed there at all, so may rather be a
>>> doc shortcoming. I've pointed this out to Intel, but I'm not expecting
>>> swift feedback.
>> We might consider dropping Cannon Lake.  It did ship 1 limited-release
>> parts, but only for laptop/tablet SKUs, and there is a reason why it has
>> been totally discontinued.
> How would you envision "dropping" to look like: Do you mean just to
> remove the case label here (and perhaps similar ones elsewhere), or
> outright refuse booting on it?

Just dropping the case labels.  No point going out of the way to
prohibit booting as, even with these dropped, the result would be
generally usable.

> In both cases if I were to submit such a change I'm afraid I'd want
> to be a little less vague in the description than to just say "there
> is a reason why it has been totally discontinued".

Its not really a secret.  It was an experiment with a 10nm lithography
process which didn't pan out.  It has been formally discontinued.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel