[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] x86/intel: insert Ice Lake-X (server) and Ice Lake-D model numbers


  • To: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 27 Jan 2021 09:52:32 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VQCeBU9boMi4jqUhbe+m+AZns815cl+uib/M+8ATwzI=; b=RAP/h8VazBOCIPB6cPRMsNAkOPfo7jpe8k3MWgHYgGUV8DkyiU55X0DIYfwbZBMjMy5+9SG140YLl2wB0NaZoXlbjPka3l83Q1OT+yH69Ozt009wd4xJ5JujwyUehvMAPrxSgcB3snhB8dgdwXjKjcFGfjGzPeyn53FV1sHwyeNgv8QJHmS2I9BEbNxMlOrPKhBuntTfibpHDE/pz46dNev1fRi2p2SU3sRlY7FC33Dm4WTStyiaVJo6p0TqYjqofty9U2O50sMElKxs5JlGrabWj2/Nnc9MyXRD14oJ8nl/edKO74Ix64G+rWtYjpjmJkB4/stxhkZMlw2lUB/uWA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GX8WIucfafdNagfXznqX8XTsGkaRRmbpQKFLgEOhvi6DPUbVC/YExHUKAaN0dJWZtStsehJ6ykDSP8JdHzKZ27fbg88WOxqurbZBNu9jQt/EfdPIo3NXozvW1tdafzujRsjxfokKsT5clPmjkDuKbdny/qP71NbID348+m6z3T7TjPgaf3gpvVAqEICbr3GHgtK0CDMK8xYjTpA0r3eVTrePoikJUcLxjgoxzFIiSdhZM0tzM52JeWIepxSZt9uMulst6y4zErGoIg/+OazaF3wm6KBOcqtYd3llZTEZCRKgdwNDkOautni7Rvo2hNBl3Y2/Y3zGlNDCexpA72yvOA==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <jbeulich@xxxxxxxx>, <roger.pau@xxxxxxxxxx>, <wl@xxxxxxx>, <jun.nakajima@xxxxxxxxx>, <kevin.tian@xxxxxxxxx>
  • Delivery-date: Wed, 27 Jan 2021 09:53:01 +0000
  • Ironport-sdr: WNnyHO0GA4mqs1fHgYqmkrx0uxKq38XQlLOe3Bv3HTujlCYbuEk3DbwPhY+KGXkMnYldF0F7Uj vhB5CtW5mITfnf5L7xUsYm6TmwOXpMRlLoposO7Oj7vWNASP44EaDEW5Ftz0fi4v4yvBYqnrKr sG830eaRccL20hxv0bZq4ozUw+mudJs7PPStroSTXPkowUlkFTZ9iA5N9txSfbeYTRl09s8voH FC/qf5Mmg7XuzYjTxu4/xaMHhfTHGDboWP9h5+wUHUojiZqsSNAvOBFQdCq1b6pbKapWpYLWjq 06A=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23/12/2020 20:32, Igor Druzhinin wrote:
> LBR, C-state MSRs should correspond to Ice Lake desktop according to
> External Design Specification vol.2 for both models.
>
> Ice Lake-X is known to expose IF_PSCHANGE_MC_NO in IA32_ARCH_CAPABILITIES MSR
> (confirmed on Whitley SDP) which means the erratum is fixed in hardware for
> that model and therefore it shouldn't be present in has_if_pschange_mc list.
> Provisionally assume the same to be the case for Ice Lake-D.
>
> Signed-off-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> ---
> Changes in v3:
> - Add Ice Lake-D model numbers
> - Drop has_if_pschange_mc hunk following Tiger Lake related discussion -
>   IF_PSCHANGE_MC_NO is confimed to be exposed on Whitley SDP
>
> ---
>  xen/arch/x86/acpi/cpu_idle.c | 2 ++
>  xen/arch/x86/hvm/vmx/vmx.c   | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
> index c092086..d788c8b 100644
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -181,6 +181,8 @@ static void do_get_hw_residencies(void *arg)
>      case 0x55:
>      case 0x5E:
>      /* Ice Lake */
> +    case 0x6A:
> +    case 0x6C:
>      case 0x7D:
>      case 0x7E:
>      /* Tiger Lake */

So I think these changes are correct.  TGL definitely has deeper
core/package states than this interface enumerates, but I can't locate
extra MSRs.

> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2d4475e..bff5979 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2775,7 +2775,7 @@ static const struct lbr_info *last_branch_msr_get(void)
>          /* Goldmont Plus */
>          case 0x7a:
>          /* Ice Lake */
> -        case 0x7d: case 0x7e:
> +        case 0x6a: case 0x6c: case 0x7d: case 0x7e:

IceLake Server has what appear to be new aspects to LBR.  I can't find
LAST_INT_INFO (0x1e0) existing in any previous generation.

However, my investigation also found LBR_SELECT which has been around
since Nehalem, which we don't handle, and Linux *does* use.

This logic is in a terrible state.  It's no surprise it is always the
first thing to break in the field.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.