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

[Ewan Hai]

On Thu, May 14, 2026 at 2:49 PM Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> wrote:
>
>
>
> On 5/14/2026 10:31 AM, Ewan Hai wrote:
> > Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> 于2026年5月13日周三 18:36写道：
> >>
> >>
> >>
> >> On 5/13/2026 5:36 PM, 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)
> >>
> >> Are these new bits really KVM-only feature bits?
> >>
> >> KVM_X86_FEATURE() is used for the features either scattered by cpufeatures.h
> >> or features that are 100% KVM-only.
> >>
> >> Kernel already has a feature word CPUID_C000_0001_EDX defined for
> >> CPUID 0xC0000001 (EDX). I think these new feature bits should be put together
> >> with the existing ones (i.e. X86_FEATURE_XSTORE, ..., X86_FEATURE_PMM_EN) in
> >> cpufeatures.h.
> >>
> >> Same for the other patches.
> >>
> >
> > Thanks for the review.
> >
> > Some history that might help. We tried the cpufeatures.h approach
> > back in April 2023:
> >
> > https://lore.kernel.org/all/20230414095334.8743-1-TonyWWang-oc@xxxxxxxxxxx/
> >
> > That didn't go in. The pushback then was that cpufeatures.h
> > additions should come with an in-kernel user of the feature, not
> > just to expose a bit. Nothing under drivers/crypto/ or lib/crypto/
> > calls these instructions, and we don't have a kernel user lined up.
> > They're unprivileged, and the practical pattern is host/guest user
> > space probing CPUID directly and calling them inline. OpenSSL's
> > PadLock engine does exactly this today for XCRYPT/XSHA, and the new
> > bits would be used the same way.
> >
> > That's why we ended up in reverse_cpuid.h, reading "no in-kernel
> > consumer" as the line between the two headers.
> >
> > If the rule has shifted and you'd rather see these in cpufeatures.h
> > next to the existing word-5 entries, we can respin as v2.
>
> Sorry, I missed the info that these are only used in user mode.
> Please ignore my previous comments.
>
No worries.

One quick clarification in case it trips up other reviewers: these
aren't user-mode only. They're unprivileged, so ring 0 can execute
them too. There's just no in-tree kernel code that does, and in
practice user space is where they actually get used.

> >
> >>
> >>> +
> >>>  struct cpuid_reg {
> >>>       u32 function;
> >>>       u32 index;
> >>
> >
>