[RFC PATCH] x86/cpu: Mark Ice Lake model 7D and 9D as unreleased

[RFC PATCH] x86/cpu: Mark Ice Lake model 7D and 9D as unreleased

[Pawan Gupta]

These models were never officially released, but they made it into
intel-family.h. There is no evidence that these models are being used in
production. As a matter of fact, Intel's affected CPU list[1] does not
contain these models.

During CPU mitigations it gets confusing whether to include these models
with other Ice Lake models or not. Add the comment in the intel-family.h to
indicate that these models were never released. Also taint and warn about
these unreleased models, except when running as a guest.

[1] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Please scream if you believe that the assumptions made in this patch are
incorrect.
---
 arch/x86/include/asm/intel-family.h |  4 ++--
 arch/x86/kernel/cpu/intel.c         | 12 ++++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index be10c188614fe24ad41e2e1912b8d5640c6ea171..948e0a057a9629dc57671e4c666b5f62e762d4bb 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -110,9 +110,9 @@
 
 #define INTEL_ICELAKE_X			IFM(6, 0x6A) /* Sunny Cove */
 #define INTEL_ICELAKE_D			IFM(6, 0x6C) /* Sunny Cove */
-#define INTEL_ICELAKE			IFM(6, 0x7D) /* Sunny Cove */
+#define INTEL_ICELAKE			IFM(6, 0x7D) /* Sunny Cove, never released */
 #define INTEL_ICELAKE_L			IFM(6, 0x7E) /* Sunny Cove */
-#define INTEL_ICELAKE_NNPI		IFM(6, 0x9D) /* Sunny Cove */
+#define INTEL_ICELAKE_NNPI		IFM(6, 0x9D) /* Sunny Cove, never released */
 
 #define INTEL_ROCKETLAKE		IFM(6, 0xA7) /* Cypress Cove */
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 076eaa41b8c81b2dd9be129d14dc7c8041eb2e79..b7eb8d5ee4351bf4a31e6a2792d24f7dbc0773ed 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -337,9 +337,21 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 		detect_tme_early(c);
 }
 
+static const struct x86_cpu_id unreleased_cpus[] = {
+	X86_MATCH_VFM(INTEL_ICELAKE,		0),
+	X86_MATCH_VFM(INTEL_ICELAKE_NNPI,	0),
+	{},
+};
+
 static void bsp_init_intel(struct cpuinfo_x86 *c)
 {
 	resctrl_cpu_detect(c);
+
+	if (x86_match_cpu(unreleased_cpus) && !cpu_has(c, X86_FEATURE_HYPERVISOR)) {
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+		WARN_ONCE(1, "WARNING: CPU family=0x%x, model=0x%x is unreleased, tainting\n",
+			  c->x86, c->x86_model);
+	}
 }
 
 #ifdef CONFIG_X86_32

---
base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
change-id: 20250514-icelake-cleanup-d7a831204d96

Best regards,
-- 
Pawan

Re: [RFC PATCH] x86/cpu: Mark Ice Lake model 7D and 9D as unreleased

[Andrew Cooper]

On 11/06/2025 7:00 pm, Pawan Gupta wrote:
> These models were never officially released, but they made it into
> intel-family.h. There is no evidence that these models are being used in
> production. As a matter of fact, Intel's affected CPU list[1] does not
> contain these models.
>
> During CPU mitigations it gets confusing whether to include these models
> with other Ice Lake models or not. Add the comment in the intel-family.h to
> indicate that these models were never released. Also taint and warn about
> these unreleased models, except when running as a guest.
>
> [1] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> Please scream if you believe that the assumptions made in this patch are
> incorrect.
> ---
>  arch/x86/include/asm/intel-family.h |  4 ++--
>  arch/x86/kernel/cpu/intel.c         | 12 ++++++++++++
>  2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
> index be10c188614fe24ad41e2e1912b8d5640c6ea171..948e0a057a9629dc57671e4c666b5f62e762d4bb 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -110,9 +110,9 @@
>  
>  #define INTEL_ICELAKE_X			IFM(6, 0x6A) /* Sunny Cove */
>  #define INTEL_ICELAKE_D			IFM(6, 0x6C) /* Sunny Cove */
> -#define INTEL_ICELAKE			IFM(6, 0x7D) /* Sunny Cove */
> +#define INTEL_ICELAKE			IFM(6, 0x7D) /* Sunny Cove, never released */
>  #define INTEL_ICELAKE_L			IFM(6, 0x7E) /* Sunny Cove */
> -#define INTEL_ICELAKE_NNPI		IFM(6, 0x9D) /* Sunny Cove */
> +#define INTEL_ICELAKE_NNPI		IFM(6, 0x9D) /* Sunny Cove, never released */

These comments are fine, although I'd suggest ", not released in the end".

>  
>  #define INTEL_ROCKETLAKE		IFM(6, 0xA7) /* Cypress Cove */
>  
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 076eaa41b8c81b2dd9be129d14dc7c8041eb2e79..b7eb8d5ee4351bf4a31e6a2792d24f7dbc0773ed 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -337,9 +337,21 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>  		detect_tme_early(c);
>  }
>  
> +static const struct x86_cpu_id unreleased_cpus[] = {
> +	X86_MATCH_VFM(INTEL_ICELAKE,		0),
> +	X86_MATCH_VFM(INTEL_ICELAKE_NNPI,	0),
> +	{},
> +};
> +
>  static void bsp_init_intel(struct cpuinfo_x86 *c)
>  {
>  	resctrl_cpu_detect(c);
> +
> +	if (x86_match_cpu(unreleased_cpus) && !cpu_has(c, X86_FEATURE_HYPERVISOR)) {
> +		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> +		WARN_ONCE(1, "WARNING: CPU family=0x%x, model=0x%x is unreleased, tainting\n",
> +			  c->x86, c->x86_model);
> +	}

I don't think this is a useful change.

What if Intel suddenly find there's a >50% gross market opportunity
selling ICX-NNPI and release this model after all?  (Ok fine, unlikely,
but the point stands).

What about unallocated model numbers?  What about A0 stepping of
released models?  What about Cannon Lake which did technically ship to
customers, but for most intents and purposes doesn't exist.

Calling these two out in isolation isn't helpful.

~Andrew

Re: [RFC PATCH] x86/cpu: Mark Ice Lake model 7D and 9D as unreleased

[Dave Hansen]

On 6/11/25 11:52, Andrew Cooper wrote:
> What if Intel suddenly find there's a >50% gross market opportunity
> selling ICX-NNPI and release this model after all?  (Ok fine, unlikely,
> but the point stands).

Intel has been _treating_ these models as if they don't exist. If Intel
changes its mind, it's going to have an awful lot of work to do like
updating the "affected CPU list" documentation or the other random CPU
model lists in the kernel that are missing ICX-NNPI.

Removing a CPU from this list will be a small matter compared to the
rest of the work that has to be done.

> What about unallocated model numbers?

One thing I considered was just taking model 7D and 9D and removing them
from the kernel. Basically making them the same as unallocated model
numbers.

But in general, we expect that folks will boot old kernels on new
hardware. We also expect the kernel to do its best there and not whine
or complain because there's nothing wrong going on.

But model 7D and 9D are different. I think we really do want the kernel
to complain. It's totally unexpected that someone will run Linux on one
of those CPUs. We want the kernel to complain loudly.

> What about A0 stepping of released models?

Can we detect A0 steppings deterministically? Do we want Linux running
on them without or without complaint?

I don't think there are any hard rules across all CPUs that would let us
reliably detect A0 steppings. Even if we could, the vast majority of
folks running Linux on them are doing internal CPU company testing on
them and we aren't going to help those folks much by scaring them with
warnings.

> What about Cannon Lake which did technically ship to customers, but
> for most intents and purposes doesn't exist.

Is there a _reason_ to mark them as unreleased? Are they getting (or did
they get) microcode updates? Are they covered in the mitigation
documentation?