All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Manali Shukla <manali.shukla@amd.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, bp@alien8.de,
	babu.moger@amd.com
Subject: Re: [RFC PATCH v1 1/4] x86/cpufeatures: Add CPUID feature bit for the Bus Lock Threshold
Date: Fri, 16 Aug 2024 12:37:52 -0700	[thread overview]
Message-ID: <Zr-qkJirOC_GM9o6@google.com> (raw)
In-Reply-To: <20240709175145.9986-2-manali.shukla@amd.com>

On Tue, Jul 09, 2024, Manali Shukla wrote:
> Malicious guests can cause bus locks to degrade the performance of

I would say "misbehaving", I bet the overwhelming majority of bus locks in practice
are due to legacy/crusty software, not malicious software.

> a system. Non-WB(write-back) and misaligned locked
> RMW(read-modify-write) instructions are referred to as "bus locks" and
> require system wide synchronization among all processors to guarantee
> atomicity.  The bus locks may incur significant performance penalties
> for all processors in the system.
> 
> The Bus Lock Threshold feature proves beneficial for hypervisors
> seeking to restrict guests' ability to initiate numerous bus locks,
> thereby preventing system slowdowns that affect all tenants.

None of this actually says what the feature does.

> Presence of the Bus Lock threshold feature is indicated via CPUID
> function 0x8000000A_EDX[29]
> 
> Signed-off-by: Manali Shukla <manali.shukla@amd.com>
> ---
>  arch/x86/include/asm/cpufeatures.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 3c7434329661..10f397873790 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -381,6 +381,7 @@
>  #define X86_FEATURE_V_SPEC_CTRL		(15*32+20) /* Virtual SPEC_CTRL */
>  #define X86_FEATURE_VNMI		(15*32+25) /* 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 */

I would strongly prefer to enumerate this in /proc/cpuinfo, having to manually
query CPUID to see if a CPU supports a feature I want to test is beyond annoying.

>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ECX), word 16 */
>  #define X86_FEATURE_AVX512VBMI		(16*32+ 1) /* AVX512 Vector Bit Manipulation instructions*/
> 
> base-commit: 704ec48fc2fbd4e41ec982662ad5bf1eee33eeb2
> -- 
> 2.34.1
> 

  reply	other threads:[~2024-08-16 19:37 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 [this message]
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
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=Zr-qkJirOC_GM9o6@google.com \
    --to=seanjc@google.com \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=manali.shukla@amd.com \
    --cc=nikunj@amd.com \
    --cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.