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