[PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Yao Zi]

Zhaoxin C4600, which names itself as CentaurHauls, claims
X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
related instructions fails with #UD exception. This will cause kernel
to crash early in current_save_fsgs().

Let's disable the feature on this problematic CPU and warn the user
about the quirk. x86_model_id is used to match the platform to avoid
unexpectedly breaking other CentaurHauls cores with conflicting
family/model ID.

Cc: stable@vger.kernel.org
Signed-off-by: Yao Zi <me@ziyao.cc>
---
 arch/x86/kernel/cpu/centaur.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 81695da9c524..3773784ba6a9 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -108,6 +108,29 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
 	}
 }
 
+/*
+ * Zhaoxin C4600 (family 6, model 15) names itself as CentaurHauls, it claims
+ * X86_FEATURE_FSGSBASE support in CPUID, while executing any fsgsbase-related
+ * instructions on it results in #UD.
+ */
+static void fixup_zhaoxin_fsgsbase(struct cpuinfo_x86 *c)
+{
+	const char *name, *model_names[] = {
+		"C-QuadCore C4600"
+	};
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(model_names); i++) {
+		name = model_names[i];
+
+		if (!strncmp(c->x86_model_id, name, strlen(name))) {
+			pr_warn_once("CPU has broken FSGSBASE support\n");
+			setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+			return;
+		}
+	}
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -201,6 +224,8 @@ static void init_centaur(struct cpuinfo_x86 *c)
 	set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
 
+	fixup_zhaoxin_fsgsbase(c);
+
 	init_ia32_feat_ctl(c);
 }
 
-- 
2.53.0

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Borislav Petkov]

On Sat, Feb 28, 2026 at 05:37:04PM +0000, Yao Zi wrote:
> Zhaoxin C4600, which names itself as CentaurHauls, claims
> X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
> related instructions fails with #UD exception. This will cause kernel
> to crash early in current_save_fsgs().
> 
> Let's disable the feature on this problematic CPU and warn the user
> about the quirk. x86_model_id is used to match the platform to avoid
> unexpectedly breaking other CentaurHauls cores with conflicting
> family/model ID.

Please use passive voice in your commit message: no "we" or "I", etc,
and describe your changes in imperative mood.

Also, pls read section "2) Describe your changes" in
Documentation/process/submitting-patches.rst for more details.

Also, see section "Changelog" in
Documentation/process/maintainer-tip.rst

> Cc: stable@vger.kernel.org
> Signed-off-by: Yao Zi <me@ziyao.cc>
> ---
>  arch/x86/kernel/cpu/centaur.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> index 81695da9c524..3773784ba6a9 100644
> --- a/arch/x86/kernel/cpu/centaur.c
> +++ b/arch/x86/kernel/cpu/centaur.c
> @@ -108,6 +108,29 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
>  	}
>  }
>  
> +/*
> + * Zhaoxin C4600 (family 6, model 15) names itself as CentaurHauls, it claims
> + * X86_FEATURE_FSGSBASE support in CPUID, while executing any fsgsbase-related
> + * instructions on it results in #UD.
> + */
> +static void fixup_zhaoxin_fsgsbase(struct cpuinfo_x86 *c)

s/fixup/disable/

> +{
> +	const char *name, *model_names[] = {
> +		"C-QuadCore C4600"
> +	};

Why is this an array with a single string in it?

> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(model_names); i++) {

So that you can loop once with it?

Silly.

> +		name = model_names[i];
> +
> +		if (!strncmp(c->x86_model_id, name, strlen(name))) {
> +			pr_warn_once("CPU has broken FSGSBASE support\n");
> +			setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +			return;
> +		}
> +	}
> +}

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Yao Zi]

On Sat, Feb 28, 2026 at 08:06:15PM +0100, Borislav Petkov wrote:
> On Sat, Feb 28, 2026 at 05:37:04PM +0000, Yao Zi wrote:
> > Zhaoxin C4600, which names itself as CentaurHauls, claims
> > X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
> > related instructions fails with #UD exception. This will cause kernel
> > to crash early in current_save_fsgs().
> > 
> > Let's disable the feature on this problematic CPU and warn the user
> > about the quirk. x86_model_id is used to match the platform to avoid
> > unexpectedly breaking other CentaurHauls cores with conflicting
> > family/model ID.
> 
> Please use passive voice in your commit message: no "we" or "I", etc,
> and describe your changes in imperative mood.
> 
> Also, pls read section "2) Describe your changes" in
> Documentation/process/submitting-patches.rst for more details.
> 
> Also, see section "Changelog" in
> Documentation/process/maintainer-tip.rst

Okay.

> > Cc: stable@vger.kernel.org
> > Signed-off-by: Yao Zi <me@ziyao.cc>
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> > index 81695da9c524..3773784ba6a9 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -108,6 +108,29 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
> >  	}
> >  }
> >  
> > +/*
> > + * Zhaoxin C4600 (family 6, model 15) names itself as CentaurHauls, it claims
> > + * X86_FEATURE_FSGSBASE support in CPUID, while executing any fsgsbase-related
> > + * instructions on it results in #UD.
> > + */
> > +static void fixup_zhaoxin_fsgsbase(struct cpuinfo_x86 *c)
> 
> s/fixup/disable/

Okay.

> > +{
> > +	const char *name, *model_names[] = {
> > +		"C-QuadCore C4600"
> > +	};
> 
> Why is this an array with a single string in it?
> 
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(model_names); i++) {
> 
> So that you can loop once with it?
> 
> Silly.

Though I don't have the conditions to confirm it, it's likely other CPUs
in the same generation of designs from Zhaoxin have similar issues:
their specifications[1] are mostly identical except the core frequency,
thus they're likely the same die. So I leave a loop here to ease latter
additions if necessary. Sorry not to make it clear.

This may be a little farsight. Dave suggests declaring an x86_cpu_id
array and switching to x86_cpu_match(), do you think it's acceptable? Or
should I focus only on the known problematic model and use a simple
if to match Zhaoxin C4600 for now?

> > +		name = model_names[i];
> > +
> > +		if (!strncmp(c->x86_model_id, name, strlen(name))) {
> > +			pr_warn_once("CPU has broken FSGSBASE support\n");
> > +			setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> > +			return;
> > +		}
> > +	}
> > +}
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Regards,
Yao Zi

[1]: https://www.zhaoxin.com/qt.aspx?nid=3&typeid=90

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[David Laight]

On Sun, 1 Mar 2026 09:27:29 +0000
Yao Zi <me@ziyao.cc> wrote:

> On Sat, Feb 28, 2026 at 08:06:15PM +0100, Borislav Petkov wrote:
> > On Sat, Feb 28, 2026 at 05:37:04PM +0000, Yao Zi wrote:  
> > > Zhaoxin C4600, which names itself as CentaurHauls, claims
> > > X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
> > > related instructions fails with #UD exception. This will cause kernel
> > > to crash early in current_save_fsgs().
> > > 
> > > Let's disable the feature on this problematic CPU and warn the user
> > > about the quirk. x86_model_id is used to match the platform to avoid
> > > unexpectedly breaking other CentaurHauls cores with conflicting
> > > family/model ID.  
> > 
> > Please use passive voice in your commit message: no "we" or "I", etc,
> > and describe your changes in imperative mood.
> > 
> > Also, pls read section "2) Describe your changes" in
> > Documentation/process/submitting-patches.rst for more details.
> > 
> > Also, see section "Changelog" in
> > Documentation/process/maintainer-tip.rst  
> 
> Okay.
> 
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Yao Zi <me@ziyao.cc>
> > > ---
> > >  arch/x86/kernel/cpu/centaur.c | 25 +++++++++++++++++++++++++
> > >  1 file changed, 25 insertions(+)
> > > 
> > > diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> > > index 81695da9c524..3773784ba6a9 100644
> > > --- a/arch/x86/kernel/cpu/centaur.c
> > > +++ b/arch/x86/kernel/cpu/centaur.c
> > > @@ -108,6 +108,29 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
> > >  	}
> > >  }
> > >  
> > > +/*
> > > + * Zhaoxin C4600 (family 6, model 15) names itself as CentaurHauls, it claims
> > > + * X86_FEATURE_FSGSBASE support in CPUID, while executing any fsgsbase-related
> > > + * instructions on it results in #UD.
> > > + */
> > > +static void fixup_zhaoxin_fsgsbase(struct cpuinfo_x86 *c)  
> > 
> > s/fixup/disable/  
> 
> Okay.
> 
> > > +{
> > > +	const char *name, *model_names[] = {
> > > +		"C-QuadCore C4600"
> > > +	};  
> > 
> > Why is this an array with a single string in it?
> >   
> > > +	int i;
> > > +
> > > +	for (i = 0; i < ARRAY_SIZE(model_names); i++) {  
> > 
> > So that you can loop once with it?
> > 
> > Silly.  
> 
> Though I don't have the conditions to confirm it, it's likely other CPUs
> in the same generation of designs from Zhaoxin have similar issues:
> their specifications[1] are mostly identical except the core frequency,
> thus they're likely the same die. So I leave a loop here to ease latter
> additions if necessary. Sorry not to make it clear.
> 
> This may be a little farsight. Dave suggests declaring an x86_cpu_id
> array and switching to x86_cpu_match(), do you think it's acceptable? Or
> should I focus only on the known problematic model and use a simple
> if to match Zhaoxin C4600 for now?

Is it possible to try executing one of the instructions and see if it traps?
That saves having to maintain a list of broken cpu.

	David

> 
> > > +		name = model_names[i];
> > > +
> > > +		if (!strncmp(c->x86_model_id, name, strlen(name))) {
> > > +			pr_warn_once("CPU has broken FSGSBASE support\n");
> > > +			setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> > > +			return;
> > > +		}
> > > +	}
> > > +}  
> > 
> > -- 
> > Regards/Gruss,
> >     Boris.
> > 
> > https://people.kernel.org/tglx/notes-about-netiquette  
> 
> Regards,
> Yao Zi
> 
> [1]: https://www.zhaoxin.com/qt.aspx?nid=3&typeid=90
> 

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Yao Zi]

On Sun, Mar 01, 2026 at 06:37:47PM +0000, David Laight wrote:
> On Sun, 1 Mar 2026 09:27:29 +0000
> Yao Zi <me@ziyao.cc> wrote:
> 
> > On Sat, Feb 28, 2026 at 08:06:15PM +0100, Borislav Petkov wrote:
> > > On Sat, Feb 28, 2026 at 05:37:04PM +0000, Yao Zi wrote:  
> > > > Zhaoxin C4600, which names itself as CentaurHauls, claims
> > > > X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
> > > > related instructions fails with #UD exception. This will cause kernel
> > > > to crash early in current_save_fsgs().
> > > > 
> > > > Let's disable the feature on this problematic CPU and warn the user
> > > > about the quirk. x86_model_id is used to match the platform to avoid
> > > > unexpectedly breaking other CentaurHauls cores with conflicting
> > > > family/model ID.  
> > > 
> > > Please use passive voice in your commit message: no "we" or "I", etc,
> > > and describe your changes in imperative mood.
> > > 
> > > Also, pls read section "2) Describe your changes" in
> > > Documentation/process/submitting-patches.rst for more details.
> > > 
> > > Also, see section "Changelog" in
> > > Documentation/process/maintainer-tip.rst  
> > 
> > Okay.
> > 
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Yao Zi <me@ziyao.cc>
> > > > ---
> > > >  arch/x86/kernel/cpu/centaur.c | 25 +++++++++++++++++++++++++
> > > >  1 file changed, 25 insertions(+)
> > > > 
> > > > diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> > > > index 81695da9c524..3773784ba6a9 100644
> > > > --- a/arch/x86/kernel/cpu/centaur.c
> > > > +++ b/arch/x86/kernel/cpu/centaur.c
> > > > @@ -108,6 +108,29 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
> > > >  	}
> > > >  }
> > > >  
> > > > +/*
> > > > + * Zhaoxin C4600 (family 6, model 15) names itself as CentaurHauls, it claims
> > > > + * X86_FEATURE_FSGSBASE support in CPUID, while executing any fsgsbase-related
> > > > + * instructions on it results in #UD.
> > > > + */
> > > > +static void fixup_zhaoxin_fsgsbase(struct cpuinfo_x86 *c)  
> > > 
> > > s/fixup/disable/  
> > 
> > Okay.
> > 
> > > > +{
> > > > +	const char *name, *model_names[] = {
> > > > +		"C-QuadCore C4600"
> > > > +	};  
> > > 
> > > Why is this an array with a single string in it?
> > >   
> > > > +	int i;
> > > > +
> > > > +	for (i = 0; i < ARRAY_SIZE(model_names); i++) {  
> > > 
> > > So that you can loop once with it?
> > > 
> > > Silly.  
> > 
> > Though I don't have the conditions to confirm it, it's likely other CPUs
> > in the same generation of designs from Zhaoxin have similar issues:
> > their specifications[1] are mostly identical except the core frequency,
> > thus they're likely the same die. So I leave a loop here to ease latter
> > additions if necessary. Sorry not to make it clear.
> > 
> > This may be a little farsight. Dave suggests declaring an x86_cpu_id
> > array and switching to x86_cpu_match(), do you think it's acceptable? Or
> > should I focus only on the known problematic model and use a simple
> > if to match Zhaoxin C4600 for now?
> 
> Is it possible to try executing one of the instructions and see if it traps?
> That saves having to maintain a list of broken cpu.

Sounds like a good idea, I'll give it a try with extable.

> 	David

Regards,
Yao Zi

> > 
> > > > +		name = model_names[i];
> > > > +
> > > > +		if (!strncmp(c->x86_model_id, name, strlen(name))) {
> > > > +			pr_warn_once("CPU has broken FSGSBASE support\n");
> > > > +			setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> > > > +			return;
> > > > +		}
> > > > +	}
> > > > +}  
> > > 
> > > -- 
> > > Regards/Gruss,
> > >     Boris.
> > > 
> > > https://people.kernel.org/tglx/notes-about-netiquette  
> > 
> > Regards,
> > Yao Zi
> > 
> > [1]: https://www.zhaoxin.com/qt.aspx?nid=3&typeid=90
> > 
> 

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Dave Hansen]

On 2/28/26 09:37, Yao Zi wrote:
> Let's disable the feature on this problematic CPU and warn the user
> about the quirk. x86_model_id is used to match the platform to avoid
> unexpectedly breaking other CentaurHauls cores with conflicting
> family/model ID.

Wait a sec. There are lots of different microarchitectures with the same
family/model and no other way to identify them but the model id string?

We've used string in a handful of places, but it's an absolute last
resort. Are you *sure* there's no stepping or anything?

I kinda think we should keep this like all the other vendors and keep it
to model/family/stepping. If the vendor has grouped too many
non-vulnerable CPUs under that, then ... this is going to be a good
learning to bring back to the CPU design team.

If you're changing the CPU in a way that it's possible to regress
things, you *need* to bump the model or stepping. Period. If you don't,
the baby might get thrown out with the bathwater.

Please resend this with a normal x86_match_cpu() and x86_cpu_id[] array.

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Yao Zi]

On Sat, Feb 28, 2026 at 04:33:18PM -0800, Dave Hansen wrote:
> On 2/28/26 09:37, Yao Zi wrote:
> > Let's disable the feature on this problematic CPU and warn the user
> > about the quirk. x86_model_id is used to match the platform to avoid
> > unexpectedly breaking other CentaurHauls cores with conflicting
> > family/model ID.
> 
> Wait a sec. There are lots of different microarchitectures with the same
> family/model and no other way to identify them but the model id string?
> 
> We've used string in a handful of places, but it's an absolute last
> resort. Are you *sure* there's no stepping or anything?

No. The commit message should be more clear, I have no clue that there
are other designs with the same family/model/stepping combination.
However, C4600 is a design from Zhaoxin instead of VIA but using
CentaurHauls as vendor ID, thus conflicts may happen since they're
different entities. So I take the safest way.

> I kinda think we should keep this like all the other vendors and keep it
> to model/family/stepping. If the vendor has grouped too many
> non-vulnerable CPUs under that, then ... this is going to be a good
> learning to bring back to the CPU design team.
> 
> If you're changing the CPU in a way that it's possible to regress
> things, you *need* to bump the model or stepping. Period. If you don't,
> the baby might get thrown out with the bathwater.
> 
> Please resend this with a normal x86_match_cpu() and x86_cpu_id[] array.

The concerns may be too farsight as there's no clue indicating conflicts
actually happened. I'll take the change in v2 if you still think it's
appropriate.

Regards,
Yao Zi

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Borislav Petkov]

On Sat, Feb 28, 2026 at 04:33:18PM -0800, Dave Hansen wrote:
> On 2/28/26 09:37, Yao Zi wrote:
> > Let's disable the feature on this problematic CPU and warn the user
> > about the quirk. x86_model_id is used to match the platform to avoid
> > unexpectedly breaking other CentaurHauls cores with conflicting
> > family/model ID.
> 
> Wait a sec. There are lots of different microarchitectures with the same
> family/model and no other way to identify them but the model id string?
> 
> We've used string in a handful of places, but it's an absolute last
> resort. Are you *sure* there's no stepping or anything?
> 
> I kinda think we should keep this like all the other vendors and keep it
> to model/family/stepping. If the vendor has grouped too many
> non-vulnerable CPUs under that, then ... this is going to be a good
> learning to bring back to the CPU design team.

Except that you'll be punishing perfectly fine CPUs... that is if those other
ones do really support the FSGSBASE set... and frankly, I don't care too
deeply if that particular zoo of models would use a model string if really
necessary.

But, the first thing we should do, is figure out whether the VIA design is
affected the same way.

Lemme CC some more folks who I can dig out from patches touching that area...

All those newly CCed folks, thread starts here:

https://lore.kernel.org/r/20260228173704.62460-1-me@ziyao.cc

Please have a look and let us know if you can whether VIA CPUs of family 6,
model 15 and use the "CentaurHauls" model string also claim that

CPUID(7)_EBX[0 /* FSGSBASE */] = 1b

but they also #UD on those insns.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Andrew Cooper]

On 28/02/2026 5:37 pm, Yao Zi wrote:
> Zhaoxin C4600, which names itself as CentaurHauls, claims
> X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
> related instructions fails with #UD exception. This will cause kernel
> to crash early in current_save_fsgs().

#UD is the expected behaviour of the FSGS instructions if they're not
enabled.

Are you saying that this specific CPU enumerates FSGSBASE in CPUID, and
permits setting CR4.FSGSBASE (without #GP for a reserved bit), and the
FSGS instructions still do not function?

What happens if you read CR4 back after trying to set the bit?

~Andrew

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Yao Zi]

On Sun, Mar 01, 2026 at 04:29:13PM +0000, Andrew Cooper wrote:
> On 28/02/2026 5:37 pm, Yao Zi wrote:
> > Zhaoxin C4600, which names itself as CentaurHauls, claims
> > X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
> > related instructions fails with #UD exception. This will cause kernel
> > to crash early in current_save_fsgs().
> 
> #UD is the expected behaviour of the FSGS instructions if they're not
> enabled.
> 
> Are you saying that this specific CPU enumerates FSGSBASE in CPUID, and
> permits setting CR4.FSGSBASE (without #GP for a reserved bit), and the
> FSGS instructions still do not function?

Yes. Without any workarounds, the kernel crashes in current_save_fsgs(),
which is the first use site of rdfsbase, instead of identify_cpu() where
CR4.FSGSBASE is set up.

> What happens if you read CR4 back after trying to set the bit?

CR4.FSGSBASE is set correctly, I wrote a small patch for testing,

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 1c3261cae40c..d89a2cc71147 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -2048,8 +2048,13 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 	setup_lass(c);
 
 	/* Enable FSGSBASE instructions if available. */
-	if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
+	if (1) {
+		pr_info("%s: enabling FSGSBASE\n", __func__);
+		pr_info("%s: before enabling, CR4 = 0x%lx\n",
+			__func__, native_read_cr4());
 		cr4_set_bits(X86_CR4_FSGSBASE);
+		pr_info("%s: after enabling, CR4 = 0x%lx\n",
+			__func__, native_read_cr4());
 		elf_hwcap2 |= HWCAP2_FSGSBASE;
 	}

On BSP I got,

[    0.298016] identify_cpu: enabling FSGSBASE
[    0.298021] identify_cpu: before enabling, CR4 = 0x1200b0
[    0.298027] identify_cpu: after enabling, CR4 = 0x1300b0

and on APs, CR4.FSGSBASE seems to be set by default,

[    0.414981] smp: Bringing up secondary CPUs ...
[    0.415211] smpboot: x86: Booting SMP configuration:
[    0.415219] .... node  #0, CPUs:      #1 #2 #3
[    0.001869] identify_cpu: enabling FSGSBASE
[    0.001869] identify_cpu: before enabling, CR4 = 0x1706b0
[    0.001869] identify_cpu: after enabling, CR4 = 0x1706b0

> ~Andrew

Regards,
Yao Zi

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Andrew Cooper]

On 02/03/2026 5:08 am, Yao Zi wrote:
> On Sun, Mar 01, 2026 at 04:29:13PM +0000, Andrew Cooper wrote:
>> On 28/02/2026 5:37 pm, Yao Zi wrote:
>>> Zhaoxin C4600, which names itself as CentaurHauls, claims
>>> X86_FEATURE_FSGSBASE support in CPUID, while execution of fsgsbase-
>>> related instructions fails with #UD exception. This will cause kernel
>>> to crash early in current_save_fsgs().
>> #UD is the expected behaviour of the FSGS instructions if they're not
>> enabled.
>>
>> Are you saying that this specific CPU enumerates FSGSBASE in CPUID, and
>> permits setting CR4.FSGSBASE (without #GP for a reserved bit), and the
>> FSGS instructions still do not function?
> Yes. Without any workarounds, the kernel crashes in current_save_fsgs(),
> which is the first use site of rdfsbase, instead of identify_cpu() where
> CR4.FSGSBASE is set up.
>
>> What happens if you read CR4 back after trying to set the bit?
> CR4.FSGSBASE is set correctly, I wrote a small patch for testing,
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 1c3261cae40c..d89a2cc71147 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -2048,8 +2048,13 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>  	setup_lass(c);
>  
>  	/* Enable FSGSBASE instructions if available. */
> -	if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
> +	if (1) {
> +		pr_info("%s: enabling FSGSBASE\n", __func__);
> +		pr_info("%s: before enabling, CR4 = 0x%lx\n",
> +			__func__, native_read_cr4());
>  		cr4_set_bits(X86_CR4_FSGSBASE);
> +		pr_info("%s: after enabling, CR4 = 0x%lx\n",
> +			__func__, native_read_cr4());
>  		elf_hwcap2 |= HWCAP2_FSGSBASE;
>  	}
>
> On BSP I got,
>
> [    0.298016] identify_cpu: enabling FSGSBASE
> [    0.298021] identify_cpu: before enabling, CR4 = 0x1200b0
> [    0.298027] identify_cpu: after enabling, CR4 = 0x1300b0
>
> and on APs, CR4.FSGSBASE seems to be set by default,
>
> [    0.414981] smp: Bringing up secondary CPUs ...
> [    0.415211] smpboot: x86: Booting SMP configuration:
> [    0.415219] .... node  #0, CPUs:      #1 #2 #3
> [    0.001869] identify_cpu: enabling FSGSBASE
> [    0.001869] identify_cpu: before enabling, CR4 = 0x1706b0
> [    0.001869] identify_cpu: after enabling, CR4 = 0x1706b0

APs inherit their configuration from the BSP.

In which case your checking logic wants to enable FSGSBASE in CR4, probe
a RDGSBASE instruction (see wrmsr_safe() for extable handling), and
clear the feature bit if the instruction faults.

This will be far more robust than looking at the brand string.

~Andrew

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Tony W Wang-oc]

Thank you for submitting the patch to fix the Zhaoxin CPU issue.

After internal clarification, we have confirmed that this is an
issue with the ZX-C CPU ucode:
When modifying CR4.FSGSBASE bit 16, the ucode propagates its
value to another MSR register. During execution of FSGSBASE-related
instructions, the hardware actually checks whether this MSR
register's bit is set to determine whether to generate a #UD
exception.
When the CPU enters SMM mode and then returns via RSM, the CR4
register is restored but the value of CR4.FSGSBASE is not
re-propagated to the MSR register.
As a result, after enabling CR4.FSGSBASE, once the CPU goes
through SMM mode, executing FSGSBASE-related instructions will
trigger a #UD exception.

This issue exists only on ZX-C CPUs, which have two different
CPU vendor IDs and distinct FMS values. The following patch can
be used to identify ZX-C CPUs and properly handle this issue:

--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -201,6 +201,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
  #endif

+       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {
+               pr_warn_once("CPU has broken FSGSBASE support; clear 
FSGSBASE feature\n");
+               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+       }
+
         init_ia32_feat_ctl(c);
  }

diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
index 031379b7d4fa..6a2d6df307ee 100644
--- a/arch/x86/kernel/cpu/zhaoxin.c
+++ b/arch/x86/kernel/cpu/zhaoxin.c
@@ -89,6 +89,11 @@ static void init_zhaoxin(struct cpuinfo_x86 *c)
         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
  #endif

+       if (c->x86 == 6 && c->x86_model == 25 && c->x86_stepping <= 3) {
+               pr_warn_once("CPU has broken FSGSBASE support; clear 
FSGSBASE feature\n");
+               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+       }
+
         init_ia32_feat_ctl(c);
  }

Sincerely
TonyWWang-oc

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Andrew Cooper]

On 05/03/2026 9:03 am, Tony W Wang-oc wrote:
> Thank you for submitting the patch to fix the Zhaoxin CPU issue.
>
> After internal clarification, we have confirmed that this is an
> issue with the ZX-C CPU ucode:
> When modifying CR4.FSGSBASE bit 16, the ucode propagates its
> value to another MSR register. During execution of FSGSBASE-related
> instructions, the hardware actually checks whether this MSR
> register's bit is set to determine whether to generate a #UD
> exception.
> When the CPU enters SMM mode and then returns via RSM, the CR4
> register is restored but the value of CR4.FSGSBASE is not
> re-propagated to the MSR register.
> As a result, after enabling CR4.FSGSBASE, once the CPU goes
> through SMM mode, executing FSGSBASE-related instructions will
> trigger a #UD exception. 

/sigh, SMM strikes again.

As this is a ucode bug, can it not be fixed with a ucode update to RSM?

~Andrew

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Yao Zi]

On Thu, Mar 05, 2026 at 05:03:07PM +0800, Tony W Wang-oc wrote:
> Thank you for submitting the patch to fix the Zhaoxin CPU issue.
> 
> After internal clarification, we have confirmed that this is an
> issue with the ZX-C CPU ucode:
> When modifying CR4.FSGSBASE bit 16, the ucode propagates its
> value to another MSR register. During execution of FSGSBASE-related
> instructions, the hardware actually checks whether this MSR
> register's bit is set to determine whether to generate a #UD
> exception.
> When the CPU enters SMM mode and then returns via RSM, the CR4
> register is restored but the value of CR4.FSGSBASE is not
> re-propagated to the MSR register.
> As a result, after enabling CR4.FSGSBASE, once the CPU goes
> through SMM mode, executing FSGSBASE-related instructions will
> trigger a #UD exception.

Thanks for confirming the issue and the explanation!

> This issue exists only on ZX-C CPUs, which have two different
> CPU vendor IDs and distinct FMS values. The following patch can
> be used to identify ZX-C CPUs and properly handle this issue:

However, I agree with Andrew that a ucode update, if possible, would
be the preferred way of fixing the issue up.

> --- a/arch/x86/kernel/cpu/centaur.c
> +++ b/arch/x86/kernel/cpu/centaur.c
> @@ -201,6 +201,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
>         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>  #endif
> 
> +       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {

Are this condition and the one below in zhaoxin.c precise enough to
recognize all and only the affected ZX-C models, without mistaking
unaffected designs even from VIA? Please see also my concerns raised
previously[1].

Though I haven't tried yet, since reproduction of the problem requires
entrance to SMM at least once, it may be hard to detect the quirk by
executing rdfsbase and seeing whether it traps. So if the conditions are
precise enough and a microcode fix isn't appropriate, I'd like to stick
with CPUID matching in v2.

David, Andrew, is it okay for you?

> +               pr_warn_once("CPU has broken FSGSBASE support; clear
> FSGSBASE feature\n");
> +               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +       }
> +
>         init_ia32_feat_ctl(c);
>  }
> 
> diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
> index 031379b7d4fa..6a2d6df307ee 100644
> --- a/arch/x86/kernel/cpu/zhaoxin.c
> +++ b/arch/x86/kernel/cpu/zhaoxin.c
> @@ -89,6 +89,11 @@ static void init_zhaoxin(struct cpuinfo_x86 *c)
>         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>  #endif
> 
> +       if (c->x86 == 6 && c->x86_model == 25 && c->x86_stepping <= 3) {
> +               pr_warn_once("CPU has broken FSGSBASE support; clear
> FSGSBASE feature\n");
> +               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +       }
> +
>         init_ia32_feat_ctl(c);
>  }
> 
> Sincerely
> TonyWWang-oc

Much thanks for the information.

Best regards,
Yao Zi

[1]: https://lore.kernel.org/lkml/aaQCLOMdJCWNF-dA@pie/

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Andrew Cooper]

On 05/03/2026 2:04 pm, Yao Zi wrote:
> On Thu, Mar 05, 2026 at 05:03:07PM +0800, Tony W Wang-oc wrote:
>> Thank you for submitting the patch to fix the Zhaoxin CPU issue.
>>
>> After internal clarification, we have confirmed that this is an
>> issue with the ZX-C CPU ucode:
>> When modifying CR4.FSGSBASE bit 16, the ucode propagates its
>> value to another MSR register. During execution of FSGSBASE-related
>> instructions, the hardware actually checks whether this MSR
>> register's bit is set to determine whether to generate a #UD
>> exception.
>> When the CPU enters SMM mode and then returns via RSM, the CR4
>> register is restored but the value of CR4.FSGSBASE is not
>> re-propagated to the MSR register.
>> As a result, after enabling CR4.FSGSBASE, once the CPU goes
>> through SMM mode, executing FSGSBASE-related instructions will
>> trigger a #UD exception.
> Thanks for confirming the issue and the explanation!
>
>> This issue exists only on ZX-C CPUs, which have two different
>> CPU vendor IDs and distinct FMS values. The following patch can
>> be used to identify ZX-C CPUs and properly handle this issue:
> However, I agree with Andrew that a ucode update, if possible, would
> be the preferred way of fixing the issue up.
>
>> --- a/arch/x86/kernel/cpu/centaur.c
>> +++ b/arch/x86/kernel/cpu/centaur.c
>> @@ -201,6 +201,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
>>         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>>  #endif
>>
>> +       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {
> Are this condition and the one below in zhaoxin.c precise enough to
> recognize all and only the affected ZX-C models, without mistaking
> unaffected designs even from VIA? Please see also my concerns raised
> previously[1].
>
> Though I haven't tried yet, since reproduction of the problem requires
> entrance to SMM at least once, it may be hard to detect the quirk by
> executing rdfsbase and seeing whether it traps. So if the conditions are
> precise enough and a microcode fix isn't appropriate, I'd like to stick
> with CPUID matching in v2.
>
> David, Andrew, is it okay for you?

Given the SMM observation, this cannot be probed for reliably, so will
have to have some kind of model check.

Ideally using the microcode revision matching infrastructure, assuming
that fixed ucode can be produced.

~Andrew

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[David Laight]

On Thu, 5 Mar 2026 17:03:07 +0800
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> wrote:

> Thank you for submitting the patch to fix the Zhaoxin CPU issue.
> 
> After internal clarification, we have confirmed that this is an
> issue with the ZX-C CPU ucode:
> When modifying CR4.FSGSBASE bit 16, the ucode propagates its
> value to another MSR register. During execution of FSGSBASE-related
> instructions, the hardware actually checks whether this MSR
> register's bit is set to determine whether to generate a #UD
> exception.
> When the CPU enters SMM mode and then returns via RSM, the CR4
> register is restored but the value of CR4.FSGSBASE is not
> re-propagated to the MSR register.
> As a result, after enabling CR4.FSGSBASE, once the CPU goes
> through SMM mode, executing FSGSBASE-related instructions will
> trigger a #UD exception.
> 
> This issue exists only on ZX-C CPUs, which have two different
> CPU vendor IDs and distinct FMS values. The following patch can
> be used to identify ZX-C CPUs and properly handle this issue:
> 
> --- a/arch/x86/kernel/cpu/centaur.c
> +++ b/arch/x86/kernel/cpu/centaur.c
> @@ -201,6 +201,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
>          set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>   #endif
> 
> +       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {

The '>= 14' looks odd to me.
It implies it all worked, got broken, and will never be fixed.
I'd also add a 1-line comment, something like:
		/* CR4.FSGSBASE not copied to MSR on return from SMM mode. */

	David

> +               pr_warn_once("CPU has broken FSGSBASE support; clear 
> FSGSBASE feature\n");
> +               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +       }
> +
>          init_ia32_feat_ctl(c);
>   }
> 
> diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
> index 031379b7d4fa..6a2d6df307ee 100644
> --- a/arch/x86/kernel/cpu/zhaoxin.c
> +++ b/arch/x86/kernel/cpu/zhaoxin.c
> @@ -89,6 +89,11 @@ static void init_zhaoxin(struct cpuinfo_x86 *c)
>          set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>   #endif
> 
> +       if (c->x86 == 6 && c->x86_model == 25 && c->x86_stepping <= 3) {
> +               pr_warn_once("CPU has broken FSGSBASE support; clear 
> FSGSBASE feature\n");
> +               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +       }
> +
>          init_ia32_feat_ctl(c);
>   }
> 
> Sincerely
> TonyWWang-oc
> 

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Dave Hansen]

On 3/5/26 01:03, Tony W Wang-oc wrote:
> --- a/arch/x86/kernel/cpu/zhaoxin.c
> +++ b/arch/x86/kernel/cpu/zhaoxin.c
> @@ -89,6 +89,11 @@ static void init_zhaoxin(struct cpuinfo_x86 *c)
>         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>  #endif
> 
> +       if (c->x86 == 6 && c->x86_model == 25 && c->x86_stepping <= 3) {
> +               pr_warn_once("CPU has broken FSGSBASE support; clear
> FSGSBASE feature\n");
> +               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +       }
> +

Folks, we have vendor-generic infrastructure to handle these today. You
don't need to hack copied and pasted code across vendor-specific files.
You just need some "VFM" defines for the models:

#define Z_MODEL_HERE	VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 26)
#define C_MODEL_HERE	VFM_MAKE(X86_VENDOR_ZHAOXIN, ...)

a table:

static const struct x86_cpu_id bum_fsgsbase[] __initconst = {
	X86_MATCH_VFM_STEPS(Z_MODEL_HERE, X86_STEP_MIN, 0x3, 1),
	X86_MATCH_VFM_STEPS(C_MODEL_HERE, ..., 1),
};

and this code:

	if (x86_match_cpu(bum_fsgsbase))
		setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);

That code happens _once_. You can even call it from vendor-independent code.

If you get fixed microcode that can also be extended to store a fixed
microcode version (although we're moving away from doing this on Intel).

Just please give the models some semi-sane model name.

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Tony W Wang-oc]

Hi Dave/Andrew/David/Yaozi,

Sorry for the late reply.

First of all, this bug was present in certain early ucode patches for 
ZX-C/ZX-C+ series CPUs; however, it has since been resolved in 
subsequent updates to the ZX-C/ZX-C+ ucode patch.

According to available documentation, the VIA Eden platform supports 
FSGSBASE; however, this CPU is too old, and we haven't been able to 
locate actual hardware to test whether it was affected by this bug.

It is recommended that, in addition to the existing FMS-based detection, 
a supplementary check be implemented to identify the specific ucode 
patch revisions associated with ZX-C/ZX-C+ that are known to exhibit 
this bug.

Due to differences in ucode matching rules on Zhaoxin platforms, 
existing kernel function interfaces cannot be used, so the patch code 
has been placed in a vendor-specific file. The specific patching 
approach can be as follows:

--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -8,6 +8,7 @@
  #include <asm/e820/api.h>
  #include <asm/mtrr.h>
  #include <asm/msr.h>
+#include <asm/microcode.h>

  #include "cpu.h"

@@ -110,6 +111,8 @@ static void early_init_centaur(struct cpuinfo_x86 *c)

  static void init_centaur(struct cpuinfo_x86 *c)
  {
+       u32 chip_pf, dummy;
+
  #ifdef CONFIG_X86_32
         char *name;
         u32  fcr_set = 0;
@@ -201,6 +204,18 @@ static void init_centaur(struct cpuinfo_x86 *c)
         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
  #endif

+       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {
+               native_rdmsr(0x1232, dummy, chip_pf);
+               chip_pf = (chip_pf >> 15) & 0x7;
+               c->microcode = intel_get_microcode_revision();
+
+               if ((chip_pf == 0 && c->microcode < 0x20e) ||
+                       (chip_pf == 1 && c->microcode < 0x208)) {
+                       pr_warn_once("CPU has broken FSGSBASE support; 
clear FSGSBASE feature\n");
+                       setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+               }
+       }
+
         init_ia32_feat_ctl(c);
  }

diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
index 031379b7d4fa..0a0525320502 100644
--- a/arch/x86/kernel/cpu/zhaoxin.c
+++ b/arch/x86/kernel/cpu/zhaoxin.c
@@ -5,6 +5,7 @@
  #include <asm/cpu.h>
  #include <asm/cpufeature.h>
  #include <asm/msr.h>
+#include <asm/microcode.h>

  #include "cpu.h"

@@ -68,6 +69,8 @@ static void early_init_zhaoxin(struct cpuinfo_x86 *c)

  static void init_zhaoxin(struct cpuinfo_x86 *c)
  {
+       u32 chip_pf, dummy;
+
         early_init_zhaoxin(c);
         init_intel_cacheinfo(c);

@@ -89,6 +92,18 @@ static void init_zhaoxin(struct cpuinfo_x86 *c)
         set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
  #endif

+       if (c->x86 == 6 && c->x86_model == 25 && c->x86_stepping <= 3) {
+               native_rdmsr(0x1232, dummy, chip_pf);
+               chip_pf = (chip_pf >> 15) & 0x7;
+               c->microcode = intel_get_microcode_revision();
+
+               if ((chip_pf == 0 && c->microcode < 0x20e) ||
+                       (chip_pf == 1 && c->microcode < 0x208)) {
+                       pr_warn_once("CPU has broken FSGSBASE support; 
clear FSGSBASE feature\n");
+                       setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+               }
+       }
+
         init_ia32_feat_ctl(c);
  }


Sincerely!
TonyWWang-oc

On 2026/3/6 00:20, Dave Hansen wrote:
> 
> 
> [这封邮件来自外部发件人 谨防风险]
> 
> On 3/5/26 01:03, Tony W Wang-oc wrote:
>> --- a/arch/x86/kernel/cpu/zhaoxin.c
>> +++ b/arch/x86/kernel/cpu/zhaoxin.c
>> @@ -89,6 +89,11 @@ static void init_zhaoxin(struct cpuinfo_x86 *c)
>>          set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
>>   #endif
>>
>> +       if (c->x86 == 6 && c->x86_model == 25 && c->x86_stepping <= 3) {
>> +               pr_warn_once("CPU has broken FSGSBASE support; clear
>> FSGSBASE feature\n");
>> +               setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
>> +       }
>> +
> 
> Folks, we have vendor-generic infrastructure to handle these today. You
> don't need to hack copied and pasted code across vendor-specific files.
> You just need some "VFM" defines for the models:
> 
> #define Z_MODEL_HERE    VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 26)
> #define C_MODEL_HERE    VFM_MAKE(X86_VENDOR_ZHAOXIN, ...)
> 
> a table:
> 
> static const struct x86_cpu_id bum_fsgsbase[] __initconst = {
>          X86_MATCH_VFM_STEPS(Z_MODEL_HERE, X86_STEP_MIN, 0x3, 1),
>          X86_MATCH_VFM_STEPS(C_MODEL_HERE, ..., 1),
> };
> 
> and this code:
> 
>          if (x86_match_cpu(bum_fsgsbase))
>                  setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> 
> That code happens _once_. You can even call it from vendor-independent code.
> 
> If you get fixed microcode that can also be extended to store a fixed
> microcode version (although we're moving away from doing this on Intel).
> 
> Just please give the models some semi-sane model name.

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Dave Hansen]

On 3/11/26 19:14, Tony W Wang-oc wrote:
> 
> 
> +       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {
> +               native_rdmsr(0x1232, dummy, chip_pf);
> +               chip_pf = (chip_pf >> 15) & 0x7;
> +               c->microcode = intel_get_microcode_revision();
> +
> +               if ((chip_pf == 0 && c->microcode < 0x20e) ||
> +                       (chip_pf == 1 && c->microcode < 0x208)) {
> +                       pr_warn_once("CPU has broken FSGSBASE support;
> clear FSGSBASE feature\n");
> +                       setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +               }
> +       }

So, I'm sorry but that's not really consistent how we're doing things
these days.

The model needs a symbolic name.

The MSR you're reading is completely undocumented and unnamed.

"chip_pf" is nonsensical and unexplained.

Code is duplicated across the centaur and zhaoxin files.

Once you have all of that fixed, you should have a simple:

#define CENTAUR_MODEL_FOO VFM_MAKE(X86_VENDOR_CENTAUR, 6, 15)
#define ZHAOXIN_MODEL_BAR VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 25)

in a central header, plus:

struct x86_cpu_id *naughty_list[] = {
	X86_MATCH_VFM_STEPS(CENTAUR_MODEL_FOO,       14, MAX_STEP, 0),
	X86_MATCH_VFM_STEPS(ZHAOXIN_MODEL_BAR, MIN_STEP,        3, 0),
	{}
};

void check_fsgsbase_bugs()
{
	u32 fixed_ucode;

	if (!cpu_feature_enabled(X86_FEATURE_FSGSBASE))
		return;

	c = x86_match_cpu(naughty_list);
	if (!c)
		return;

	chip_pf = ...
	if (chip_pf == 0)
		fixed_ucode = 0x20e;
	if (chip_pf == 1)
		fixed_ucode = 0x208;

	if (intel_get_microcode_revision() >= fixed_ucode)
		return;

	pr_warn_once("Broken FSGSBASE support, clearing feature\n");
	setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
}

Then check_fsgsbase_bugs() can pretty much be called anywhere. It can
even be in generic code.

We are also getting some new matching fields in 'x86_cpu_id'. I suspect
'chip_pf' can be stored in there where Intel has the platform_id right
now. But you don't have to do that now.

Could you please go this route rather than copy-and-pasted chunks of
code sprinkled with a healthy dose of magic numbers?

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Tony W Wang-oc]

On 2026/3/12 23:52, Dave Hansen wrote:
> On 3/11/26 19:14, Tony W Wang-oc wrote:
>>
>> +       if (c->x86 == 6 && c->x86_model == 15 && c->x86_stepping >= 14) {
>> +               native_rdmsr(0x1232, dummy, chip_pf);
>> +               chip_pf = (chip_pf >> 15) & 0x7;
>> +               c->microcode = intel_get_microcode_revision();
>> +
>> +               if ((chip_pf == 0 && c->microcode < 0x20e) ||
>> +                       (chip_pf == 1 && c->microcode < 0x208)) {
>> +                       pr_warn_once("CPU has broken FSGSBASE support;
>> clear FSGSBASE feature\n");
>> +                       setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
>> +               }
>> +       }
> So, I'm sorry but that's not really consistent how we're doing things
> these days.
>
> The model needs a symbolic name.
>
> The MSR you're reading is completely undocumented and unnamed.
Sorry, MSR 0x1232 is a Zhaoxin private MSR. Currently, this MSR is not 
documented in any public specification. It is used to store CPU 
manufacturing information.
>
> "chip_pf" is nonsensical and unexplained.
chip_pf retrieved from MSR 0x1232 represents the CPU product version.
>
> Code is duplicated across the centaur and zhaoxin files.
>
> Once you have all of that fixed, you should have a simple:
>
> #define CENTAUR_MODEL_FOO VFM_MAKE(X86_VENDOR_CENTAUR, 6, 15)
> #define ZHAOXIN_MODEL_BAR VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 25)
>
> in a central header, plus:
>
> struct x86_cpu_id *naughty_list[] = {
> 	X86_MATCH_VFM_STEPS(CENTAUR_MODEL_FOO,       14, MAX_STEP, 0),
> 	X86_MATCH_VFM_STEPS(ZHAOXIN_MODEL_BAR, MIN_STEP,        3, 0),
> 	{}
> };
>
> void check_fsgsbase_bugs()
> {
> 	u32 fixed_ucode;
>
> 	if (!cpu_feature_enabled(X86_FEATURE_FSGSBASE))
> 		return;
>
> 	c = x86_match_cpu(naughty_list);
> 	if (!c)
> 		return;
>
> 	chip_pf = ...
> 	if (chip_pf == 0)
> 		fixed_ucode = 0x20e;
> 	if (chip_pf == 1)
> 		fixed_ucode = 0x208;
>
> 	if (intel_get_microcode_revision() >= fixed_ucode)
> 		return;
>
> 	pr_warn_once("Broken FSGSBASE support, clearing feature\n");
> 	setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> }
>
> Then check_fsgsbase_bugs() can pretty much be called anywhere. It can
> even be in generic code.
>
> We are also getting some new matching fields in 'x86_cpu_id'. I suspect
> 'chip_pf' can be stored in there where Intel has the platform_id right
> now. But you don't have to do that now.
>
> Could you please go this route rather than copy-and-pasted chunks of
> code sprinkled with a healthy dose of magic numbers?
Thank you for providing the example code.

Could you please take another look at the following patch to see if it's 
acceptable?

diff --git a/MAINTAINERS b/MAINTAINERS
index 364f0bec8748..42093a794056 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29168,6 +29168,7 @@ ZHAOXIN PROCESSOR SUPPORT
  M:    Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
  L:    linux-kernel@vger.kernel.org
  S:    Maintained
+F:    arch/x86/include/asm/zhaoxin.h
  F:    arch/x86/kernel/cpu/zhaoxin.c

  ZONED BLOCK DEVICE (BLOCK LAYER)
diff --git a/arch/x86/include/asm/msr-index.h 
b/arch/x86/include/asm/msr-index.h
index be3e3cc963b2..dc71a4adc776 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -1306,5 +1306,7 @@
                          * disabling x2APIC will cause
                          * a #GP
                          */
+/* ZHAOXIN defined MSRs*/
+#define MSR_ZHAOXIN_MFGID        0x00001232

  #endif /* _ASM_X86_MSR_INDEX_H */
diff --git a/arch/x86/include/asm/zhaoxin.h b/arch/x86/include/asm/zhaoxin.h
new file mode 100644
index 000000000000..a3883bb149b4
--- /dev/null
+++ b/arch/x86/include/asm/zhaoxin.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ZHAOXIN_H
+#define _ASM_X86_ZHAOXIN_H
+
+#include <asm/cpu_device_id.h>
+#include <asm/microcode.h>
+
+#define    ZHAOXIN_MODEL_ZXC    VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 25)
+#define    CENTAUR_MODEL_ZXC    VFM_MAKE(X86_VENDOR_CENTAUR, 6, 15)
+
+struct x86_cpu_id naughty_list[] = {
+    X86_MATCH_VFM_STEPS(ZHAOXIN_MODEL_ZXC, 0, 3, 0),
+    X86_MATCH_VFM_STEPS(CENTAUR_MODEL_ZXC, 14, 15, 0),
+    {}
+};
+
+void check_fsgsbase_bugs(void);
+
+void check_fsgsbase_bugs(void)
+{
+
+    u32 chip_pf, dummy, fixed_ucode;
+
+    if (!cpu_feature_enabled(X86_FEATURE_FSGSBASE))
+        return;
+
+    if (!x86_match_cpu(naughty_list))
+        return;
+
+    native_rdmsr(MSR_ZHAOXIN_MFGID, dummy, chip_pf);
+
+    /* chip_pf represents product version flag */
+    chip_pf = (chip_pf >> 15) & 0x7;
+
+    if (chip_pf == 0)
+        fixed_ucode = 0x20e;
+    if (chip_pf == 1)
+        fixed_ucode = 0x208;
+
+    if (intel_get_microcode_revision() >= fixed_ucode)
+        return;
+
+    pr_warn_once("Broken FSGSBASE support, clearing feature\n");
+    setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+}
+
+#endif
+
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 1c3261cae40c..fe24830a47aa 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -73,6 +73,7 @@
  #include <asm/tdx.h>
  #include <asm/posted_intr.h>
  #include <asm/runtime-const.h>
+#include <asm/zhaoxin.h>

  #include "cpu.h"

@@ -2047,6 +2048,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
      setup_umip(c);
      setup_lass(c);

+    check_fsgsbase_bugs();
+
      /* Enable FSGSBASE instructions if available. */
      if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
          cr4_set_bits(X86_CR4_FSGSBASE);

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Dave Hansen]

> --- /dev/null
> +++ b/arch/x86/include/asm/zhaoxin.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_X86_ZHAOXIN_H
> +#define _ASM_X86_ZHAOXIN_H
> +
> +#include <asm/cpu_device_id.h>
> +#include <asm/microcode.h>
> +
> +#define    ZHAOXIN_MODEL_ZXC    VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 25)
> +#define    CENTAUR_MODEL_ZXC    VFM_MAKE(X86_VENDOR_CENTAUR, 6, 15)
> +
> +struct x86_cpu_id naughty_list[] = {
> +    X86_MATCH_VFM_STEPS(ZHAOXIN_MODEL_ZXC, 0, 3, 0),
> +    X86_MATCH_VFM_STEPS(CENTAUR_MODEL_ZXC, 14, 15, 0),
> +    {}
> +};

Hi Tony,

This is headed in the right direction, in a way.

However, I think you might have missed a few things. Did you notice that
this structure is in a .h file? We generally don't define data
structures and variables in header files. You might want to take a quick
look around the tree.

Then, go try and #include this header in two different places. See what
happens.

> +void check_fsgsbase_bugs(void);
> +
> +void check_fsgsbase_bugs(void)
> +{

Generally, compiler warnings are good things. They tell you that you've
done something wrong. Simply throwing code in to silence them isn't a
great practice.

Remember the compiler warning you got without the function declaration?
That was there to tell you that something is wrong. You placed
definitions in a header, not declarations.

But, adding a declaration before the definition made the compiler quiet.

> +    u32 chip_pf, dummy, fixed_ucode;

This is whitespace damaged, btw.

I also prefer one variable per line

	u32 fixed_ucode;
	u32 chip_pf;
	u32 dummy;

> +    if (!cpu_feature_enabled(X86_FEATURE_FSGSBASE))
> +        return;
> +
> +    if (!x86_match_cpu(naughty_list))
> +        return;

Heh, also I was joking about 'naughty_list'. It would be best to give it
a good symbolic, meaningful name.

> +    native_rdmsr(MSR_ZHAOXIN_MFGID, dummy, chip_pf);

This at least need commenting. What prevents this code from getting
called on other vendors' CPUs? What about models of Zhaoxin CPUs that
don't have this MSR?

> +    /* chip_pf represents product version flag */
> +    chip_pf = (chip_pf >> 15) & 0x7;

Please use the GENMASK macros here.

> +    if (chip_pf == 0)
> +        fixed_ucode = 0x20e;
> +    if (chip_pf == 1)
> +        fixed_ucode = 0x208;
> +
> +    if (intel_get_microcode_revision() >= fixed_ucode)
> +        return;

It's probably worth commenting why this is calling an "intel"_ function.

> +    pr_warn_once("Broken FSGSBASE support, clearing feature\n");
> +    setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
> +}
> +
> +#endif

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Tony W Wang-oc]

On 2026/3/17 23:21, Dave Hansen wrote:
>> --- /dev/null
>> +++ b/arch/x86/include/asm/zhaoxin.h
>> @@ -0,0 +1,48 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_X86_ZHAOXIN_H
>> +#define _ASM_X86_ZHAOXIN_H
>> +
>> +#include <asm/cpu_device_id.h>
>> +#include <asm/microcode.h>
>> +
>> +#define    ZHAOXIN_MODEL_ZXC    VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 25)
>> +#define    CENTAUR_MODEL_ZXC    VFM_MAKE(X86_VENDOR_CENTAUR, 6, 15)
>> +
>> +struct x86_cpu_id naughty_list[] = {
>> +    X86_MATCH_VFM_STEPS(ZHAOXIN_MODEL_ZXC, 0, 3, 0),
>> +    X86_MATCH_VFM_STEPS(CENTAUR_MODEL_ZXC, 14, 15, 0),
>> +    {}
>> +};
> Hi Tony,
>
> This is headed in the right direction, in a way.
>
> However, I think you might have missed a few things. Did you notice that
> this structure is in a .h file? We generally don't define data
> structures and variables in header files. You might want to take a quick
> look around the tree.
>
> Then, go try and #include this header in two different places. See what
> happens.
>
>> +void check_fsgsbase_bugs(void);
>> +
>> +void check_fsgsbase_bugs(void)
>> +{
> Generally, compiler warnings are good things. They tell you that you've
> done something wrong. Simply throwing code in to silence them isn't a
> great practice.
>
> Remember the compiler warning you got without the function declaration?
> That was there to tell you that something is wrong. You placed
> definitions in a header, not declarations.
>
> But, adding a declaration before the definition made the compiler quiet.
>
>> +    u32 chip_pf, dummy, fixed_ucode;
> This is whitespace damaged, btw.
>
> I also prefer one variable per line
>
> 	u32 fixed_ucode;
> 	u32 chip_pf;
> 	u32 dummy;
>
>> +    if (!cpu_feature_enabled(X86_FEATURE_FSGSBASE))
>> +        return;
>> +
>> +    if (!x86_match_cpu(naughty_list))
>> +        return;
> Heh, also I was joking about 'naughty_list'. It would be best to give it
> a good symbolic, meaningful name.
>
>> +    native_rdmsr(MSR_ZHAOXIN_MFGID, dummy, chip_pf);
> This at least need commenting. What prevents this code from getting
> called on other vendors' CPUs? What about models of Zhaoxin CPUs that
> don't have this MSR?
>
>> +    /* chip_pf represents product version flag */
>> +    chip_pf = (chip_pf >> 15) & 0x7;
> Please use the GENMASK macros here.
>
>> +    if (chip_pf == 0)
>> +        fixed_ucode = 0x20e;
>> +    if (chip_pf == 1)
>> +        fixed_ucode = 0x208;
>> +
>> +    if (intel_get_microcode_revision() >= fixed_ucode)
>> +        return;
> It's probably worth commenting why this is calling an "intel"_ function.
>
>> +    pr_warn_once("Broken FSGSBASE support, clearing feature\n");
>> +    setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
>> +}
>> +
>> +#endif
>
Sorry, The previous patch didn't consider the generality of the newly 
added zhaoxin.h.  The intention was to minimize modifications to common.c.

The revised patch is provided below, please review it again. Thank you.

iff --git a/MAINTAINERS b/MAINTAINERS
index 364f0bec8748..42093a794056 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29168,6 +29168,7 @@ ZHAOXIN PROCESSOR SUPPORT
  M:    Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
  L:    linux-kernel@vger.kernel.org
  S:    Maintained
+F:    arch/x86/include/asm/zhaoxin.h
  F:    arch/x86/kernel/cpu/zhaoxin.c

  ZONED BLOCK DEVICE (BLOCK LAYER)
diff --git a/arch/x86/include/asm/msr-index.h 
b/arch/x86/include/asm/msr-index.h
index be3e3cc963b2..dc71a4adc776 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -1306,5 +1306,7 @@
                          * disabling x2APIC will cause
                          * a #GP
                          */
+/* ZHAOXIN defined MSRs*/
+#define MSR_ZHAOXIN_MFGID        0x00001232

  #endif /* _ASM_X86_MSR_INDEX_H */
diff --git a/arch/x86/include/asm/zhaoxin.h b/arch/x86/include/asm/zhaoxin.h
new file mode 100644
index 000000000000..e7f380b678dc
--- /dev/null
+++ b/arch/x86/include/asm/zhaoxin.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ZHAOXIN_H
+#define _ASM_X86_ZHAOXIN_H
+
+#include <asm/cpu_device_id.h>
+#include <asm/microcode.h>
+
+#define    ZHAOXIN_MODEL_ZXC    VFM_MAKE(X86_VENDOR_ZHAOXIN, 6, 25)
+#define    CENTAUR_MODEL_ZXC    VFM_MAKE(X86_VENDOR_CENTAUR, 6, 15)
+
+extern struct x86_cpu_id fsgsbase_bugs_list[];
+extern void check_fsgsbase_bugs(void);
+
+#endif
+
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 1c3261cae40c..49e58b55c414 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -73,6 +73,7 @@
  #include <asm/tdx.h>
  #include <asm/posted_intr.h>
  #include <asm/runtime-const.h>
+#include <asm/zhaoxin.h>

  #include "cpu.h"

@@ -1940,6 +1941,50 @@ void check_null_seg_clears_base(struct 
cpuinfo_x86 *c)
      set_cpu_bug(c, X86_BUG_NULL_SEG);
  }

+struct x86_cpu_id fsgsbase_bugs_list[] = {
+    X86_MATCH_VFM_STEPS(ZHAOXIN_MODEL_ZXC, 0, 3, 0),
+    X86_MATCH_VFM_STEPS(CENTAUR_MODEL_ZXC, 14, 15, 0),
+    {}
+};
+
+void check_fsgsbase_bugs(void)
+{
+    u32 chip_pf;
+    u32 dummy;
+    u32 fixed_ucode;
+
+    if (!cpu_feature_enabled(X86_FEATURE_FSGSBASE))
+        return;
+
+    if (!x86_match_cpu(fsgsbase_bugs_list))
+        return;
+
+    /*
+     * All Zhaoxin CPUs use MSR_ZHAOXIN_MFGID to represent
+     * manufacturing information. Please note that this MSR
+     * may have different meanings in other vendors' CPUs.
+     */
+    native_rdmsr(MSR_ZHAOXIN_MFGID, dummy, chip_pf);
+
+    /* chip_pf represents product version flag */
+    chip_pf = (chip_pf & GENMASK(17, 15)) >> 15;
+
+    if (chip_pf == 0)
+        fixed_ucode = 0x20e;
+    if (chip_pf == 1)
+        fixed_ucode = 0x208;
+
+    /*
+     * Zhaoxin ucode version retrieval method is compatible
+     * with Intel.
+     */
+    if (intel_get_microcode_revision() >= fixed_ucode)
+        return;
+
+    pr_warn_once("Broken FSGSBASE support, clearing feature\n");
+    setup_clear_cpu_cap(X86_FEATURE_FSGSBASE);
+}
+
  static void generic_identify(struct cpuinfo_x86 *c)
  {
      c->extended_cpuid_level = 0;
@@ -2047,6 +2092,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
      setup_umip(c);
      setup_lass(c);

+    check_fsgsbase_bugs();
+
      /* Enable FSGSBASE instructions if available. */
      if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
          cr4_set_bits(X86_CR4_FSGSBASE);

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Christian Ludloff]

Tony,

can you confirm whether F=6 M=1F is affected or not?
(Supposedly that's ZX-D... but the F in the model does
make me wonder/ask.)

Presumably the 6FE and 10690 microcodes which are
out in the wild do not fix the bug, correct?

000006fe_00000000_20110809_8f396f73
000006fe_00000000_20110809_8f397072
000006fe_00000001_20160525_7214d1e1
000006fe_00000001_20170109_25646399
000006fe_00000001_20180726_6e07329b
000006fe_00000001_20180726_6e1e984b

00010690_00000000_20110809_259878a5
00010690_00000001_20160525_3c34fc1a
00010690_00000001_20170109_a8b24dc2
00010690_00000001_20180726_0c55f25d
00010690_00000001_20180726_41faefde

As for making the code conditional for Centaur/Zhaoxin,
stepping E seems to be when FSGSBASE arrived – and
while there are CPUID dumps for 6FE that say VIA Eden
it is possible that they too have the bug.

As for making the code conditional for Zhaoxin models in
the string, that would require more than just C4600 – the
collection of known dumps includes others.

--
C.

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Tony W Wang-oc]

On 2026/3/6 04:26, Christian Ludloff wrote:
> 
> 
> Tony,
> 
> can you confirm whether F=6 M=1F is affected or not?
> (Supposedly that's ZX-D... but the F in the model does
> make me wonder/ask.)
> 
This bug existed only in certain early ucode revisions of the ZX-C/ZX-C+ 
series CPUs, and is not present in the ZX-D.

> Presumably the 6FE and 10690 microcodes which are
> out in the wild do not fix the bug, correct?
> 
> 000006fe_00000000_20110809_8f396f73
> 000006fe_00000000_20110809_8f397072
> 000006fe_00000001_20160525_7214d1e1
> 000006fe_00000001_20170109_25646399
> 000006fe_00000001_20180726_6e07329b
> 000006fe_00000001_20180726_6e1e984b
> 
> 00010690_00000000_20110809_259878a5
> 00010690_00000001_20160525_3c34fc1a
> 00010690_00000001_20170109_a8b24dc2
> 00010690_00000001_20180726_0c55f25d
> 00010690_00000001_20180726_41faefde
>
No, The four patches with the display date of 20180726 should not have 
this bug.

> As for making the code conditional for Centaur/Zhaoxin,
> stepping E seems to be when FSGSBASE arrived – and
> while there are CPUID dumps for 6FE that say VIA Eden
> it is possible that they too have the bug.
> 
Sorry, VIA Eden is too old, we haven't been able to find actual hardware 
to confirm this.

> As for making the code conditional for Zhaoxin models in
> the string, that would require more than just C4600 – the
> collection of known dumps includes others.
> 
Yes, ZX-C/ZX-C+ series CPUs have other strings.

Sincerely!
TonyWWang-oc
> --
> C.

Re: [PATCH] x86/cpu/centaur: Disable X86_FEATURE_FSGSBASE on Zhaoxin C4600

[Christian Ludloff]

much appreciated – many thanks!

--
C.

On Wed, Mar 11, 2026 at 7:19 PM Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> wrote:
>
>
>
> On 2026/3/6 04:26, Christian Ludloff wrote:
> >
> >
> > Tony,
> >
> > can you confirm whether F=6 M=1F is affected or not?
> > (Supposedly that's ZX-D... but the F in the model does
> > make me wonder/ask.)
> >
> This bug existed only in certain early ucode revisions of the ZX-C/ZX-C+
> series CPUs, and is not present in the ZX-D.
>
> > Presumably the 6FE and 10690 microcodes which are
> > out in the wild do not fix the bug, correct?
> >
> > 000006fe_00000000_20110809_8f396f73
> > 000006fe_00000000_20110809_8f397072
> > 000006fe_00000001_20160525_7214d1e1
> > 000006fe_00000001_20170109_25646399
> > 000006fe_00000001_20180726_6e07329b
> > 000006fe_00000001_20180726_6e1e984b
> >
> > 00010690_00000000_20110809_259878a5
> > 00010690_00000001_20160525_3c34fc1a
> > 00010690_00000001_20170109_a8b24dc2
> > 00010690_00000001_20180726_0c55f25d
> > 00010690_00000001_20180726_41faefde
> >
> No, The four patches with the display date of 20180726 should not have
> this bug.
>
> > As for making the code conditional for Centaur/Zhaoxin,
> > stepping E seems to be when FSGSBASE arrived – and
> > while there are CPUID dumps for 6FE that say VIA Eden
> > it is possible that they too have the bug.
> >
> Sorry, VIA Eden is too old, we haven't been able to find actual hardware
> to confirm this.
>
> > As for making the code conditional for Zhaoxin models in
> > the string, that would require more than just C4600 – the
> > collection of known dumps includes others.
> >
> Yes, ZX-C/ZX-C+ series CPUs have other strings.
>
> Sincerely!
> TonyWWang-oc
> > --
> > C.