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