Message ID | 20221019084734.3590760-2-jiaxi.chen@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp211989wrs; Wed, 19 Oct 2022 02:06:25 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7+3vOTpXc73fqmKOZgEbz6rWnJRyg9zYDrqTfz5Bk/39MMfnUJCCaLzcN5wPtwrtThm2EQ X-Received: by 2002:a05:6402:2926:b0:459:675b:38a9 with SMTP id ee38-20020a056402292600b00459675b38a9mr6475484edb.60.1666170385118; Wed, 19 Oct 2022 02:06:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666170385; cv=none; d=google.com; s=arc-20160816; b=CF5iSUYV0kpKi36Oo1SmpRTWJY6mjLrn0wk7rDUQfMN/NcmTsXNSr1TjKzQ+5LGbAg mxWRFeuHRNpEkTALSc0wgJsh3bkDX6qjm/T98mRv3ql+F/BrOC2IXUDCkB5L9+gDzwk/ zT0w9QvelH6hPJo/GobVuZCjdRIHFS4E7lzE0tt6x7Mk7L891SKJDLiEqa18y5nqE4O4 Bf7ecuA0w6O5/Mqyln/khv2F3mYYDY+WpteBk7ZPeB43DYxPciPQeIQPsleXdVtFojhG C12c8SBOsuPwEXU677+e8fYSUohyocQbopggizaTgoFbec7EIj49jdb7EibM8NyP8H9E HDHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=TIu1vIT1gmp2mlUk+lnDsruC5qhHa/Pui/O2o3xQEwo=; b=t+2drFR1r0PMR4I6ULwKO8MLi+WxYfk/7LQHgxVI//1x2zIrG7M8h/oGWlS5uJ1NL8 cZYvTgMDUgk4zaRQUvSC9RWW+eMro6C4G2O+fHL+2iKiPqlwAWdJf43HuJtjuk9n243f XL7Sw1lg0dvEY1qHXm416Unby44RkeGYH9ntYNYO5GKLxK91EKhSqw9Totj/kQO+98PB t+Mr1Ou9cVjwx6Aaqr6Qy4dA7Isppz7X5QhrPsRGDuuADGjO22Mf1j8C+6rS8aWq9aVN qq4+Wk/0qyZAl5qJ5fSkqWsJQvvsSYSezoyZ/jyKOiiu/cV5aPRAhjbxPZesWQbKk92P GFYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RjHTlC5c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dn15-20020a17090794cf00b007919a242731si5522899ejc.95.2022.10.19.02.05.56; Wed, 19 Oct 2022 02:06:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RjHTlC5c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231776AbiJSI5D (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 04:57:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231950AbiJSI40 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 04:56:26 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DEF652479; Wed, 19 Oct 2022 01:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666169565; x=1697705565; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aN1z8mG+6FtVyNG8T1B6yk4JgG7etoGpqzlwCguutHU=; b=RjHTlC5clSe6EgBqvr3QFVOpn22g9Q3pVRE4XFeBMMPBSJ41cUqWkASw /VzXldnn0tipfKpgqNHMTZHfkYNxgsAWUOw1YB49ks+mfR86r+PuH83pc u5VD9QrUZkuWjJwfTADviemQIdlN2/jLUFUhsQ0qWT/pCmfjoOwvgzwcw dezP8knaaeciF1iGq4dFwCBDybLs9k7rDuoxwE0c2vcjiqMKJNB7f5fSj PrCVvaNlB3F5xLmwJY98E5NXPG36y2N4UNOYrujE0s4xanujQwkSQL6zu ESZpHYiLZNTxBw3lc2EtT27HRcYDTqRpdMM5Bmpa53MmwPKkODHj/MSiS g==; X-IronPort-AV: E=McAfee;i="6500,9779,10504"; a="286065913" X-IronPort-AV: E=Sophos;i="5.95,195,1661842800"; d="scan'208";a="286065913" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 01:47:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10504"; a="804195844" X-IronPort-AV: E=Sophos;i="5.95,195,1661842800"; d="scan'208";a="804195844" Received: from jiaxichen-precision-3650-tower.sh.intel.com ([10.239.159.75]) by orsmga005.jf.intel.com with ESMTP; 19 Oct 2022 01:47:39 -0700 From: Jiaxi Chen <jiaxi.chen@linux.intel.com> To: kvm@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, ndesaulniers@google.com, alexandre.belloni@bootlin.com, peterz@infradead.org, jiaxi.chen@linux.intel.com, jpoimboe@kernel.org, chang.seok.bae@intel.com, pawan.kumar.gupta@linux.intel.com, babu.moger@amd.com, jmattson@google.com, sandipan.das@amd.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, fenghua.yu@intel.com, keescook@chromium.org, jane.malalane@citrix.com, nathan@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/6] x86: KVM: Enable CMPccXADD CPUID and expose it to guest Date: Wed, 19 Oct 2022 16:47:29 +0800 Message-Id: <20221019084734.3590760-2-jiaxi.chen@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221019084734.3590760-1-jiaxi.chen@linux.intel.com> References: <20221019084734.3590760-1-jiaxi.chen@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747106277880034550?= X-GMAIL-MSGID: =?utf-8?q?1747106277880034550?= |
Series |
x86: KVM: Expose CPUID to guest for new Intel platform instructions
|
|
Commit Message
Jiaxi Chen
Oct. 19, 2022, 8:47 a.m. UTC
CMPccXADD is a new set of instructions in the latest Intel platform Sierra
Forest. It includes a semaphore operation that can compare and add the
operands if condition is met, which can improve database performance.
The bit definition:
CPUID.(EAX=7,ECX=1):EAX[bit 7]
This patch enables this CPUID in the kernel feature bits and expose it to
guest OS.
Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kvm/cpuid.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
Comments
For all the shortlogs, "expose it to guest" is technically wrong. Adding recognition in kvm/cpuid.c advertises KVM support to host userspace. Whether or not a feature is exposed to the guest is up to the userspace VMM. On Wed, Oct 19, 2022, Jiaxi Chen wrote: > CMPccXADD is a new set of instructions in the latest Intel platform Sierra > Forest. It includes a semaphore operation that can compare and add the In general, avoid pronouns in changelogs, it's not clear what "it" refers to here. And for all of these changelogs, please explicitly state that there are no VMX controls for these instructions, assuming that's actually true. From a KVM perspective, that's far more interesting than the details of the instruction(s). > operands if condition is met, which can improve database performance. > > The bit definition: > CPUID.(EAX=7,ECX=1):EAX[bit 7] > > This patch enables this CPUID in the kernel feature bits and expose it to > guest OS. Same thing here, KVM doesn't decide whether or not to expose the feature to the guest. > Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> > --- > arch/x86/include/asm/cpufeatures.h | 1 + > arch/x86/kvm/cpuid.c | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h > index ef4775c6db01..445626cb5779 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -308,6 +308,7 @@ > /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ > #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ > #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */ > +#define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructions */ Boris, What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, KVM passthrough is the only reason the existing features are defined.
在 2022/10/19 23:15, Sean Christopherson 写道: > For all the shortlogs, "expose it to guest" is technically wrong. Adding > recognition in kvm/cpuid.c advertises KVM support to host userspace. Whether or > not a feature is exposed to the guest is up to the userspace VMM. Thanks for reminding. How about to change the subject to this: x86: KVM: Advertise CMPccXADD CPUID to userspace > > On Wed, Oct 19, 2022, Jiaxi Chen wrote: >> CMPccXADD is a new set of instructions in the latest Intel platform Sierra >> Forest. It includes a semaphore operation that can compare and add the > > In general, avoid pronouns in changelogs, it's not clear what "it" refers to here. > Will change it to: 'This new instruction set' here and avoid use pronouns in the future commit message. > And for all of these changelogs, please explicitly state that there are no VMX > controls for these instructions, assuming that's actually true. From a KVM > perspective, that's far more interesting than the details of the instruction(s). > Yes, thanks for comments. Will change this patch series to: This instruction has no other VMX control except for exposed to userspace. >> operands if condition is met, which can improve database performance. >> >> The bit definition: >> CPUID.(EAX=7,ECX=1):EAX[bit 7] >> >> This patch enables this CPUID in the kernel feature bits and expose it to >> guest OS. > > Same thing here, KVM doesn't decide whether or not to expose the feature to the > guest. > Applied.Thanks. >> Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> >> --- >> arch/x86/include/asm/cpufeatures.h | 1 + >> arch/x86/kvm/cpuid.c | 2 +- >> 2 files changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h >> index ef4775c6db01..445626cb5779 100644 >> --- a/arch/x86/include/asm/cpufeatures.h >> +++ b/arch/x86/include/asm/cpufeatures.h >> @@ -308,6 +308,7 @@ >> /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ >> #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ >> #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */ >> +#define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructions */ > > Boris, > > What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, > KVM passthrough is the only reason the existing features are defined.
On 10/19/2022 11:15 PM, Sean Christopherson wrote: > For all the shortlogs, "expose it to guest" is technically wrong. Adding > recognition in kvm/cpuid.c advertises KVM support to host userspace. Whether or > not a feature is exposed to the guest is up to the userspace VMM. > > On Wed, Oct 19, 2022, Jiaxi Chen wrote: >> CMPccXADD is a new set of instructions in the latest Intel platform Sierra >> Forest. It includes a semaphore operation that can compare and add the > > In general, avoid pronouns in changelogs, it's not clear what "it" refers to here. > > And for all of these changelogs, please explicitly state that there are no VMX > controls for these instructions, assuming that's actually true. From a KVM > perspective, that's far more interesting than the details of the instruction(s). > >> operands if condition is met, which can improve database performance. >> >> The bit definition: >> CPUID.(EAX=7,ECX=1):EAX[bit 7] >> >> This patch enables this CPUID in the kernel feature bits and expose it to >> guest OS. > > Same thing here, KVM doesn't decide whether or not to expose the feature to the > guest. > >> Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> >> --- >> arch/x86/include/asm/cpufeatures.h | 1 + >> arch/x86/kvm/cpuid.c | 2 +- >> 2 files changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h >> index ef4775c6db01..445626cb5779 100644 >> --- a/arch/x86/include/asm/cpufeatures.h >> +++ b/arch/x86/include/asm/cpufeatures.h >> @@ -308,6 +308,7 @@ >> /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ >> #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ >> #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */ >> +#define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructions */ > > Boris, > > What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, > KVM passthrough is the only reason the existing features are defined. Boris, Since CPUID_7_1_EAX has only 5 features now, it is a big waste, should we move it to KVM-only leaf as Sean suggested. What's your opinion about this?
On Wed, Oct 26, 2022 at 11:40:31AM +0800, Jiaxi Chen wrote: > > What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, > > KVM passthrough is the only reason the existing features are defined. Yap, looking at the patches which added those 2 feature flags upstream, they don't look like some particular use was the goal but rather to expose it to guests. Besides, AVX512 apps do their own CPUID detection. > Since CPUID_7_1_EAX has only 5 features now, it is a big waste, > should we move it to KVM-only leaf as Sean suggested. What's your > opinion about this? Yes, pls do. And when you do, make sure to undo what b302e4b176d0 ("x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions") added. Thx.
On 10/27/2022 1:15 AM, Borislav Petkov wrote: > On Wed, Oct 26, 2022 at 11:40:31AM +0800, Jiaxi Chen wrote: >>> What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, >>> KVM passthrough is the only reason the existing features are defined. > > Yap, looking at the patches which added those 2 feature flags upstream, > they don't look like some particular use was the goal but rather to > expose it to guests. Besides, AVX512 apps do their own CPUID detection. > >> Since CPUID_7_1_EAX has only 5 features now, it is a big waste, >> should we move it to KVM-only leaf as Sean suggested. What's your >> opinion about this? > > Yes, pls do. > > And when you do, make sure to undo what > > b302e4b176d0 ("x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions") > > added. > > Thx. > Yes, will do this in v2. Thanks for reminding~
On 10/27/2022 1:15 AM, Borislav Petkov wrote: > On Wed, Oct 26, 2022 at 11:40:31AM +0800, Jiaxi Chen wrote: >>> What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, >>> KVM passthrough is the only reason the existing features are defined. > > Yap, looking at the patches which added those 2 feature flags upstream, > they don't look like some particular use was the goal but rather to > expose it to guests. Besides, AVX512 apps do their own CPUID detection. > >> Since CPUID_7_1_EAX has only 5 features now, it is a big waste, >> should we move it to KVM-only leaf as Sean suggested. What's your >> opinion about this? > > Yes, pls do. > > And when you do, make sure to undo what > > b302e4b176d0 ("x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions") > > added. > > Thx. > Hi Sean and Boris, Just realized moving CPUID_7_1_EAX to kvm-only leaf will not save space in enum cpuid_leafs[]. CPUID_7_1_EAX is indeed removed, but someone else, ie. CPUID_DUMMY needs to take the place, otherwise the cpuid_leafs array would be deranged. Therefore, the length of x86 cpuid leaves is not decreased. Wonder if the intention of moving this leaf to kvm-only is for saving space in x86_capability[], or just because there's no other use case in the host kernel side and the cpuflags of this features can be removed. Hope for your suggestions.
On Tue, Nov 01, 2022, Jiaxi Chen wrote: > > > On 10/27/2022 1:15 AM, Borislav Petkov wrote: > > On Wed, Oct 26, 2022 at 11:40:31AM +0800, Jiaxi Chen wrote: > >>> What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, > >>> KVM passthrough is the only reason the existing features are defined. > > > > Yap, looking at the patches which added those 2 feature flags upstream, > > they don't look like some particular use was the goal but rather to > > expose it to guests. Besides, AVX512 apps do their own CPUID detection. > > > >> Since CPUID_7_1_EAX has only 5 features now, it is a big waste, > >> should we move it to KVM-only leaf as Sean suggested. What's your > >> opinion about this? > > > > Yes, pls do. > > > > And when you do, make sure to undo what > > > > b302e4b176d0 ("x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions") > > > > added. > > > > Thx. > > > Hi Sean and Boris, > > Just realized moving CPUID_7_1_EAX to kvm-only leaf will not save space > in enum cpuid_leafs[]. CPUID_7_1_EAX is indeed removed, but someone > else, ie. CPUID_DUMMY needs to take the place, otherwise the cpuid_leafs > array would be deranged. Therefore, the length of x86 cpuid leaves is > not decreased. The order of "enum cpuid_leafs" is completely arbitrary. After replacing CPUID_7_1_EAX with CPUID_DUMMY, replace CPUID_DUMMY with the last leaf, which is currently CPUID_8000_001F_EAX, and update the #defines accordingly. Alternatively, Boris may prefer skipping the intermediate CPUID_DUMMY step and just replace CPUID_7_1_EAX with CPUID_8000_001F_EAX straightaway.
On 11/1/2022 11:07 PM, Sean Christopherson wrote: > On Tue, Nov 01, 2022, Jiaxi Chen wrote: >> >> >> On 10/27/2022 1:15 AM, Borislav Petkov wrote: >>> On Wed, Oct 26, 2022 at 11:40:31AM +0800, Jiaxi Chen wrote: >>>>> What do you think about moving CPUID_7_1_EAX to be a KVM-only leaf too? AFAICT, >>>>> KVM passthrough is the only reason the existing features are defined. >>> >>> Yap, looking at the patches which added those 2 feature flags upstream, >>> they don't look like some particular use was the goal but rather to >>> expose it to guests. Besides, AVX512 apps do their own CPUID detection. >>> >>>> Since CPUID_7_1_EAX has only 5 features now, it is a big waste, >>>> should we move it to KVM-only leaf as Sean suggested. What's your >>>> opinion about this? >>> >>> Yes, pls do. >>> >>> And when you do, make sure to undo what >>> >>> b302e4b176d0 ("x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions") >>> >>> added. >>> >>> Thx. >>> >> Hi Sean and Boris, >> >> Just realized moving CPUID_7_1_EAX to kvm-only leaf will not save space >> in enum cpuid_leafs[]. CPUID_7_1_EAX is indeed removed, but someone >> else, ie. CPUID_DUMMY needs to take the place, otherwise the cpuid_leafs >> array would be deranged. Therefore, the length of x86 cpuid leaves is >> not decreased. > > The order of "enum cpuid_leafs" is completely arbitrary. > > After replacing CPUID_7_1_EAX with CPUID_DUMMY, replace CPUID_DUMMY with the last > leaf, which is currently CPUID_8000_001F_EAX, and update the #defines accordingly. > Alternatively, Boris may prefer skipping the intermediate CPUID_DUMMY step and > just replace CPUID_7_1_EAX with CPUID_8000_001F_EAX straightaway. Yes, thanks for Sean's kind suggestion. I think use CPUID_DUMMY as the transition leaf will make the code logic and commit message clearer. Will change it in v2.
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index ef4775c6db01..445626cb5779 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -308,6 +308,7 @@ /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */ +#define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructions */ /* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */ #define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */ diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 7065462378e2..3f745f6fdc43 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -657,7 +657,7 @@ void kvm_set_cpu_caps(void) kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD); kvm_cpu_cap_mask(CPUID_7_1_EAX, - F(AVX_VNNI) | F(AVX512_BF16) + F(AVX_VNNI) | F(AVX512_BF16) | F(CMPCCXADD) ); kvm_cpu_cap_mask(CPUID_D_1_EAX,