[PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Jan Beulich]

Both match prior generation processors as far as LBR and C-state MSRs
go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
(recent spec updates).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Such changes having been subject to backporting in the past, this
change may want considering for 4.14.
---
I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
for Ice Lake indicating that MDS_NO may wrongly be set. But this is
apparently addressed by ucode update, so we may not need to deal with
it in software.

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -180,9 +180,15 @@ static void do_get_hw_residencies(void *
     case 0x4E:
     case 0x55:
     case 0x5E:
+    /* Ice Lake */
+    case 0x7D:
+    case 0x7E:
     /* Kaby Lake */
     case 0x8E:
     case 0x9E:
+    /* Comet Lake */
+    case 0xA5:
+    case 0xA6:
         GET_PC2_RES(hw_res->pc2);
         GET_CC7_RES(hw_res->cc7);
         /* fall through */
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2438,8 +2438,12 @@ static bool __init has_if_pschange_mc(vo
     case 0x4e: /* Skylake M */
     case 0x5e: /* Skylake D */
     case 0x55: /* Skylake-X / Cascade Lake */
+    case 0x7d: /* Ice Lake */
+    case 0x7e: /* Ice Lake */
     case 0x8e: /* Kaby / Coffee / Whiskey Lake M */
     case 0x9e: /* Kaby / Coffee / Whiskey Lake D */
+    case 0xa5: /* Comet Lake H/S */
+    case 0xa6: /* Comet Lake U */
         return true;
 
         /*
@@ -2781,10 +2785,14 @@ static const struct lbr_info *last_branc
         case 0x66:
         /* Goldmont Plus */
         case 0x7a:
+        /* Ice Lake */
+        case 0x7d: case 0x7e:
         /* Tremont */
         case 0x86:
         /* Kaby Lake */
         case 0x8e: case 0x9e:
+        /* Comet Lake */
+        case 0xa5: case 0xa6:
             return sk_lbr;
         /* Atom */
         case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36:

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Roger Pau Monné]

On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote:
> Both match prior generation processors as far as LBR and C-state MSRs
> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
> (recent spec updates).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Such changes having been subject to backporting in the past, this
> change may want considering for 4.14.
> ---
> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
> apparently addressed by ucode update, so we may not need to deal with
> it in software.
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c

What about mwait-idle? I guess we pick that from Linux and no patch
has been added so far?

Thanks, Roger.

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Jan Beulich]

On 05.06.2020 10:02, Roger Pau Monné wrote:
> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote:
>> Both match prior generation processors as far as LBR and C-state MSRs
>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
>> (recent spec updates).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Such changes having been subject to backporting in the past, this
>> change may want considering for 4.14.
>> ---
>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
>> apparently addressed by ucode update, so we may not need to deal with
>> it in software.
>>
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
> 
> What about mwait-idle? I guess we pick that from Linux and no patch
> has been added so far?

Correct. I've looked at recent history there, and I'm uncertain they'll
add further models there. They look to prefer to use ACPI _CST now again
with, as it seems, not overly much of a difference to the ACPI driver
(which, if we were to follow, I'd rather see us integrate there).

Jan

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Roger Pau Monné]

On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote:
> On 05.06.2020 10:02, Roger Pau Monné wrote:
> > On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote:
> >> Both match prior generation processors as far as LBR and C-state MSRs
> >> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
> >> (recent spec updates).
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> Such changes having been subject to backporting in the past, this
> >> change may want considering for 4.14.
> >> ---
> >> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
> >> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
> >> apparently addressed by ucode update, so we may not need to deal with
> >> it in software.
> >>
> >> --- a/xen/arch/x86/acpi/cpu_idle.c
> >> +++ b/xen/arch/x86/acpi/cpu_idle.c
> > 
> > What about mwait-idle? I guess we pick that from Linux and no patch
> > has been added so far?
> 
> Correct. I've looked at recent history there, and I'm uncertain they'll
> add further models there. They look to prefer to use ACPI _CST now again
> with, as it seems, not overly much of a difference to the ACPI driver
> (which, if we were to follow, I'd rather see us integrate there).

Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen
PoV as we didn't rely on dom0 in order to discover C states. I wonder
if we could continue to update mwait-idle on our own for newer models.

FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions,
but I'm not sure if this has been confirmed in any way?

Roger.

[0] https://en.wikichip.org/wiki/intel/cpuid#Big_Cores_.28Server.29

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Jan Beulich]

On 05.06.2020 10:46, Roger Pau Monné wrote:
> On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote:
>> On 05.06.2020 10:02, Roger Pau Monné wrote:
>>> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote:
>>>> Both match prior generation processors as far as LBR and C-state MSRs
>>>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
>>>> (recent spec updates).
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> ---
>>>> Such changes having been subject to backporting in the past, this
>>>> change may want considering for 4.14.
>>>> ---
>>>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
>>>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
>>>> apparently addressed by ucode update, so we may not need to deal with
>>>> it in software.
>>>>
>>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>>
>>> What about mwait-idle? I guess we pick that from Linux and no patch
>>> has been added so far?
>>
>> Correct. I've looked at recent history there, and I'm uncertain they'll
>> add further models there. They look to prefer to use ACPI _CST now again
>> with, as it seems, not overly much of a difference to the ACPI driver
>> (which, if we were to follow, I'd rather see us integrate there).
> 
> Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen
> PoV as we didn't rely on dom0 in order to discover C states. I wonder
> if we could continue to update mwait-idle on our own for newer models.

This would be nice indeed, but would require Intel to provide us with
the necessary data.

> FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions,
> but I'm not sure if this has been confirmed in any way?

SDM vol 4 confirms this, but mentions the two model numbers exclusively
in the table matching signatures to model names ("Future Intel Xeon
processors based on Ice Lake microarchitecture"). Without there being an
actual table for these I don't think we should "speculatively" add the
numbers anywhere.

Jan

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Roger Pau Monné]

On Fri, Jun 05, 2020 at 10:54:22AM +0200, Jan Beulich wrote:
> On 05.06.2020 10:46, Roger Pau Monné wrote:
> > On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote:
> >> On 05.06.2020 10:02, Roger Pau Monné wrote:
> >>> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote:
> >>>> Both match prior generation processors as far as LBR and C-state MSRs
> >>>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
> >>>> (recent spec updates).
> >>>>
> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>> ---
> >>>> Such changes having been subject to backporting in the past, this
> >>>> change may want considering for 4.14.
> >>>> ---
> >>>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
> >>>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
> >>>> apparently addressed by ucode update, so we may not need to deal with
> >>>> it in software.
> >>>>
> >>>> --- a/xen/arch/x86/acpi/cpu_idle.c
> >>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
> >>>
> >>> What about mwait-idle? I guess we pick that from Linux and no patch
> >>> has been added so far?
> >>
> >> Correct. I've looked at recent history there, and I'm uncertain they'll
> >> add further models there. They look to prefer to use ACPI _CST now again
> >> with, as it seems, not overly much of a difference to the ACPI driver
> >> (which, if we were to follow, I'd rather see us integrate there).
> > 
> > Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen
> > PoV as we didn't rely on dom0 in order to discover C states. I wonder
> > if we could continue to update mwait-idle on our own for newer models.
> 
> This would be nice indeed, but would require Intel to provide us with
> the necessary data.
> 
> > FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions,
> > but I'm not sure if this has been confirmed in any way?
> 
> SDM vol 4 confirms this, but mentions the two model numbers exclusively
> in the table matching signatures to model names ("Future Intel Xeon
> processors based on Ice Lake microarchitecture"). Without there being an
> actual table for these I don't think we should "speculatively" add the
> numbers anywhere.

Ack.

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Andrew Cooper]

On 05/06/2020 08:51, Jan Beulich wrote:
> Both match prior generation processors as far as LBR and C-state MSRs
> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
> (recent spec updates).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Such changes having been subject to backporting in the past, this
> change may want considering for 4.14.
> ---
> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
> apparently addressed by ucode update, so we may not need to deal with
> it in software.

I've enquired about this.  At a guess, there was another hole found, so
MDS_NO has been cleared and VERW flushing reinstated.

Either way, changes there can wait until we've got confirmation.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Andrew Cooper]

On 05/06/2020 09:54, Jan Beulich wrote:
> On 05.06.2020 10:46, Roger Pau Monné wrote:
>> On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote:
>>> On 05.06.2020 10:02, Roger Pau Monné wrote:
>>>> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote:
>>>>> Both match prior generation processors as far as LBR and C-state MSRs
>>>>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
>>>>> (recent spec updates).
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> Such changes having been subject to backporting in the past, this
>>>>> change may want considering for 4.14.
>>>>> ---
>>>>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
>>>>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
>>>>> apparently addressed by ucode update, so we may not need to deal with
>>>>> it in software.
>>>>>
>>>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>>> What about mwait-idle? I guess we pick that from Linux and no patch
>>>> has been added so far?
>>> Correct. I've looked at recent history there, and I'm uncertain they'll
>>> add further models there. They look to prefer to use ACPI _CST now again
>>> with, as it seems, not overly much of a difference to the ACPI driver
>>> (which, if we were to follow, I'd rather see us integrate there).
>> Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen
>> PoV as we didn't rely on dom0 in order to discover C states. I wonder
>> if we could continue to update mwait-idle on our own for newer models.
> This would be nice indeed, but would require Intel to provide us with
> the necessary data.
>
>> FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions,
>> but I'm not sure if this has been confirmed in any way?
> SDM vol 4 confirms this, but mentions the two model numbers exclusively
> in the table matching signatures to model names ("Future Intel Xeon
> processors based on Ice Lake microarchitecture"). Without there being an
> actual table for these I don't think we should "speculatively" add the
> numbers anywhere.

0x6a is server, 0x6c is microserver.

From this patch, 0x7d is regular client and 0x7e mobile, but there is
also 0x9d which is separate model for inference (I believe its server
with extra AVX512).

Its high time we borrowed intel-family.h from Linux and used that.

~Andrew

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Jan Beulich]

On 05.06.2020 19:37, Andrew Cooper wrote:
> On 05/06/2020 08:51, Jan Beulich wrote:
>> Both match prior generation processors as far as LBR and C-state MSRs
>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
>> (recent spec updates).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Such changes having been subject to backporting in the past, this
>> change may want considering for 4.14.
>> ---
>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
>> apparently addressed by ucode update, so we may not need to deal with
>> it in software.
> 
> I've enquired about this.  At a guess, there was another hole found, so
> MDS_NO has been cleared and VERW flushing reinstated.
> 
> Either way, changes there can wait until we've got confirmation.
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Paul - any thoughts about this one either way for 4.14?

Jan

RE: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

[Paul Durrant]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 09 June 2020 11:33
> To: Paul Durrant <paul@xen.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>; xen-devel@lists.xenproject.org; Roger Pau Monné
> <roger.pau@citrix.com>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers
> 
> On 05.06.2020 19:37, Andrew Cooper wrote:
> > On 05/06/2020 08:51, Jan Beulich wrote:
> >> Both match prior generation processors as far as LBR and C-state MSRs
> >> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum
> >> (recent spec updates).
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> Such changes having been subject to backporting in the past, this
> >> change may want considering for 4.14.
> >> ---
> >> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum
> >> for Ice Lake indicating that MDS_NO may wrongly be set. But this is
> >> apparently addressed by ucode update, so we may not need to deal with
> >> it in software.
> >
> > I've enquired about this.  At a guess, there was another hole found, so
> > MDS_NO has been cleared and VERW flushing reinstated.
> >
> > Either way, changes there can wait until we've got confirmation.
> >
> > Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Paul - any thoughts about this one either way for 4.14?
> 

I don't see any harm in it going in at this stage.

Release-acked-by: Paul Durrant <paul@xen.org>