From: Manali Shukla <manali.shukla@amd.com>
To: Borislav Petkov <bp@alien8.de>, Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
pbonzini@redhat.com, shuah@kernel.org, nikunj@amd.com,
thomas.lendacky@amd.com, vkuznets@redhat.com, babu.moger@amd.com,
Manali Shukla <manali.shukla@amd.com>
Subject: Re: [RFC PATCH v1 1/4] x86/cpufeatures: Add CPUID feature bit for the Bus Lock Threshold
Date: Fri, 20 Sep 2024 11:23:10 +0530 [thread overview]
Message-ID: <76355a11-a0ba-4a28-bf51-454facfd59e5@amd.com> (raw)
In-Reply-To: <20240830082136.GAZtGBEMyF-MbWXrPo@fat_crate.local>
On 8/30/2024 1:51 PM, Borislav Petkov wrote:
> On Thu, Aug 29, 2024 at 09:42:40PM -0700, Sean Christopherson wrote:
>> Ah, sorry, if the platform+kernel supports the feature, not just raw CPU.
>
> Yeah, that's not always trivial, as I'm sure you know. Especially if it is
> a complicated feature like, SNP, for example, which needs fw and platform to
> be configured properly and so on.
>
>> And because that utility is not available by default on most targets I care
>> about, and having to build and copy over a binary is annoying (though this
>> is a minor gripe).
>
> I'm keeping that thing as simple as possible on purpose. So if you wanna make
> it available on such targets, I'm all ears.
>
>> That said, what I really want in most cases is to know if _KVM_ supports
>> a feature. I'll think more on this, I have a few vague ideas for getting
>> a pile of information out of KVM without needing to add more uABI.
>
> That's exactly my pet peeve - making it a uABI and then supporting it foreva.
>
> We have tried to explain what cpuinfo should be:
>
> Documentation/arch/x86/cpuinfo.rst
>
> The gist of it is:
>
> "So, the current use of /proc/cpuinfo is to show features which the kernel has
> *enabled* and *supports*. As in: the CPUID feature flag is there, there's an
> additional setup which the kernel has done while booting and the functionality
> is ready to use. A perfect example for that is "user_shstk" where additional
> code enablement is present in the kernel to support shadow stack for user
> programs."
>
> So if it is something that has been enabled and is actively supported, then
> sure, ofc. What I don't want to have there is a partial mirror of every
> possible CPUID flag which is going to be a senseless and useless madness.
>
> Dunno, I guess if we had a
>
> "virt: ..."
>
> line in /proc/cpuinfo which has flags of what the hypervisor has enabled as
> a feature, it might not be such a wrong idea... with the above caveats, ofc.
> I don't think you want a flurry of patches setting all possible flags just
> because.
>
> Or maybe somewhere else where you can query it conveniently...
>
I came up with this patch. Does it look okay?
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 0b9611da6c53..74c52bfd8cf2 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -41,6 +41,7 @@ enum cpuid_leafs
#define x86_cap_flag_num(flag) ((flag) >> 5), ((flag) & 31)
extern const char * const x86_cap_flags[NCAPINTS*32];
+extern const char * const x86_virt_flags[NCAPINTS*32];
extern const char * const x86_power_flags[32];
#define X86_CAP_FMT "%s"
#define x86_cap_flag(flag) x86_cap_flags[flag]
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 734940fdb6c1..20f389ee0079 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -382,7 +382,7 @@
#define X86_FEATURE_V_SPEC_CTRL (15*32+20) /* "v_spec_ctrl" Virtual SPEC_CTRL */
#define X86_FEATURE_VNMI (15*32+25) /* "vnmi" Virtual NMI */
#define X86_FEATURE_SVME_ADDR_CHK (15*32+28) /* SVME addr check */
-#define X86_FEATURE_BUS_LOCK_THRESHOLD (15*32+29) /* "" Bus lock threshold */
+#define X86_VIRT_FEATURE_BUS_LOCK_THRESHOLD (15*32+29) /* "buslock" Bus lock threshold */
/* Intel-defined CPU features, CPUID level 0x00000007:0 (ECX), word 16 */
#define X86_FEATURE_AVX512VBMI (16*32+ 1) /* "avx512vbmi" AVX512 Vector Bit Manipulation instructions*/
diff --git a/arch/x86/kernel/cpu/mkcapflags.sh b/arch/x86/kernel/cpu/mkcapflags.sh
index 68f537347466..3671c7892c56 100644
--- a/arch/x86/kernel/cpu/mkcapflags.sh
+++ b/arch/x86/kernel/cpu/mkcapflags.sh
@@ -62,6 +62,9 @@ trap 'rm "$OUT"' EXIT
dump_array "x86_bug_flags" "NBUGINTS*32" "X86_BUG_" "NCAPINTS*32" $2
echo ""
+ dump_array "x86_virt_flags" "NCAPINTS*32" "X86_VIRT_FEATURE_" "" $2
+ echo ""
+
echo "#ifdef CONFIG_X86_VMX_FEATURE_NAMES"
echo "#ifndef _ASM_X86_VMXFEATURES_H"
echo "#include <asm/vmxfeatures.h>"
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index e65fae63660e..3068b0a110e4 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -103,6 +103,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (cpu_has(c, i) && x86_cap_flags[i] != NULL)
seq_printf(m, " %s", x86_cap_flags[i]);
+ seq_puts(m, "\nvirt\t\t:");
+ for (i = 0; i < 32*NCAPINTS; i++)
+ if (cpu_has(c, i) && x86_virt_flags[i] != NULL)
+ seq_printf(m, " %s", x86_virt_flags[i]);
+
#ifdef CONFIG_X86_VMX_FEATURE_NAMES
if (cpu_has(c, X86_FEATURE_VMX) && c->vmx_capability[0]) {
seq_puts(m, "\nvmx flags\t:");
Output for this patch from /proc/cpuinfo looks like below:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid movdiri movdir64b overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d sev sev_es sev_snp debug_swap amd_lbr_pmc_freeze
virt : buslock
bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
- Manali
next prev parent reply other threads:[~2024-09-20 5:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 17:51 [RFC PATCH v1 0/4] Add support for the Bus Lock Threshold Manali Shukla
2024-07-09 17:51 ` [RFC PATCH v1 1/4] x86/cpufeatures: Add CPUID feature bit " Manali Shukla
2024-08-16 19:37 ` Sean Christopherson
2024-08-22 9:43 ` Manali Shukla
2024-08-29 6:48 ` Borislav Petkov
2024-08-30 4:42 ` Sean Christopherson
2024-08-30 8:21 ` Borislav Petkov
2024-09-20 5:53 ` Manali Shukla [this message]
2024-07-09 17:51 ` [RFC PATCH v1 2/4] KVM: SVM: Enable Bus lock threshold exit Manali Shukla
2024-08-16 19:54 ` Sean Christopherson
2024-08-24 5:35 ` Manali Shukla
2024-08-26 16:15 ` Sean Christopherson
2024-08-29 6:37 ` Manali Shukla
2024-08-28 16:44 ` Manali Shukla
2024-07-09 17:51 ` [RFC PATCH v1 3/4] KVM: x86: nSVM: Implement support for nested Bus Lock Threshold Manali Shukla
2024-08-16 20:05 ` Sean Christopherson
2024-08-28 15:52 ` Manali Shukla
2024-08-16 20:14 ` Sean Christopherson
2024-08-29 14:32 ` Manali Shukla
2024-07-09 17:51 ` [RFC PATCH v1 4/4] KVM: selftests: Add bus lock exit test Manali Shukla
2024-08-16 20:21 ` Sean Christopherson
2024-08-26 10:29 ` Manali Shukla
2024-08-26 16:06 ` Sean Christopherson
2024-08-29 9:41 ` Manali Shukla
2024-07-30 4:52 ` [RFC PATCH v1 0/4] Add support for the Bus Lock Threshold Manali Shukla
2024-08-07 3:55 ` Manali Shukla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76355a11-a0ba-4a28-bf51-454facfd59e5@amd.com \
--to=manali.shukla@amd.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox