Re: [PATCH v1 1/5] KVM: x86: Expose Zhaoxin SM2 CPUID feature

[Ewan Hai]

Quick question before sending v2:

With the definitions moving to cpufeatures.h, there are two reasonable
ways to organize the series. Which would you prefer?

Option A (6 patches, split by subsystem):

[PATCH v2 1/6] x86/cpufeatures: Add Zhaoxin SM2 feature
[PATCH v2 2/6] x86/cpufeatures: Add Zhaoxin CCS (SM3 + SM4) feature
[PATCH v2 3/6] x86/cpufeatures: Add Zhaoxin RNG2 feature
[PATCH v2 4/6] x86/cpufeatures: Add Zhaoxin PHE2 feature
[PATCH v2 5/6] x86/cpufeatures: Add Zhaoxin RSA feature
[PATCH v2 6/6] KVM: x86: Advertise new Zhaoxin CPUID 0xC0000001 EDX bits

Option B (5 patches, each group end-to-end):

[PATCH v2 1/5] KVM: x86: Expose Zhaoxin SM2 CPUID feature
[PATCH v2 2/5] KVM: x86: Expose Zhaoxin CCS (SM3 + SM4) CPUID feature
[PATCH v2 3/5] KVM: x86: Expose Zhaoxin RNG2 CPUID feature
[PATCH v2 4/5] KVM: x86: Expose Zhaoxin PHE2 CPUID feature
[PATCH v2 5/5] KVM: x86: Expose Zhaoxin RSA CPUID feature
(each patch adds both the cpufeatures.h entry and the KVM F() use)

Either way the total diff is the same; just want to do it in the form
that's easiest to review. Any preference?

Thanks,
Ewan

On Thu, May 28, 2026 at 8:26 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Wed, May 13, 2026, Ewan Hai wrote:
> > Advertise the Zhaoxin SM2 instruction support to guests via CPUID
> > 0xC0000001 EDX bits 0 (SM2) and 1 (SM2_EN).
> >
> > The SM2 instruction (encoding F2 0F A6 C0) implements the SM2
> > elliptic-curve public-key cryptography algorithm specified in
> > GM/T 0003-2012; the hardware-level behavior is documented in the
> > Zhaoxin GMI Instruction Set Reference, chapter 1 ("SM2"). The
> > instruction multiplexes its sub-functions on the RDX[5:0] control
> > word: encryption (subsection 1.1), decryption (1.2), signing (1.3),
> > signature verification (1.4), the three key-exchange sub-operations
> > of section 1.5 (1.5.1 SM2 key-pair generation, which the spec also
> > uses for the initiator's ephemeral key; 1.5.2 responder shared-key
> > derivation; 1.5.3 initiator shared-key derivation), and two
> > preprocess steps for identity and message hashing (1.6.1 and 1.6.2).
> >
> > The instruction is user-mode and available in all CPU modes, with no
> > associated MSR control. The SM2 and SM2_EN bits are redundant by
> > hardware design (set or cleared together) and both serve purely as
> > CPUID-level feature-presence reporting flags requiring no KVM
> > emulation. Both bits are advertised because different software may
> > probe either one when checking for SM2 availability.
> >
> > Signed-off-by: Ewan Hai <ewandevelop@xxxxxxxxx>
> > ---
> >  arch/x86/kvm/cpuid.c         | 2 ++
> >  arch/x86/kvm/reverse_cpuid.h | 4 ++++
> >  2 files changed, 6 insertions(+)
> >
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index e69156b54cff..1eb4b88aaa80 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -1272,6 +1272,8 @@ void kvm_initialize_cpu_caps(void)
> >               kvm_cpu_cap_set(X86_FEATURE_NULL_SEL_CLR_BASE);
> >
> >       kvm_cpu_cap_init(CPUID_C000_0001_EDX,
> > +             F(SM2),
> > +             F(SM2_EN),
> >               F(XSTORE),
> >               F(XSTORE_EN),
> >               F(XCRYPT),
> > diff --git a/arch/x86/kvm/reverse_cpuid.h b/arch/x86/kvm/reverse_cpuid.h
> > index 657f5f743ed9..7b55110cc046 100644
> > --- a/arch/x86/kvm/reverse_cpuid.h
> > +++ b/arch/x86/kvm/reverse_cpuid.h
> > @@ -76,6 +76,10 @@
> >  #define KVM_X86_FEATURE_TSA_SQ_NO    KVM_X86_FEATURE(CPUID_8000_0021_ECX, 1)
> >  #define KVM_X86_FEATURE_TSA_L1_NO    KVM_X86_FEATURE(CPUID_8000_0021_ECX, 2)
> >
> > +/* Zhaoxin/Centaur sub-features, CPUID level 0xC0000001 (EDX) */
> > +#define X86_FEATURE_SM2                      KVM_X86_FEATURE(CPUID_C000_0001_EDX, 0)
> > +#define X86_FEATURE_SM2_EN           KVM_X86_FEATURE(CPUID_C000_0001_EDX, 1)
>
> Oh, just define the X86_FEATURE_xx flags in arch/x86/include/asm/cpufeatures.h,
> all of word 5 is carved out for the leaf.
>
> Features are defined arch/x86/kvm/reverse_cpuid.h (versus cpufeatures.h) only
> when the feature is "scattered" (not guaranteed to be at its architectural bit
> position) in cpufeatures.h, or is not defined at all (because the kernel doesn't
> use or care about the feature.
>
> The changelogs all look great!
>