Linux Kernel Selftest development
 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 2/4] KVM: SVM: Enable Bus lock threshold exit
Date: Mon, 26 Aug 2024 09:15:20 -0700	[thread overview]
Message-ID: <ZsyqGGspHOsuyEBY@google.com> (raw)
In-Reply-To: <cf8c67de-4c23-416c-a268-56a12801a305@amd.com>

On Sat, Aug 24, 2024, Manali Shukla wrote:
> > Actually, we already have a capability, which means there's zero reason for this
> > module param to exist.  Userspace already has to opt-in to turning on bus lock
> > detection, i.e. userspace already has the opportunity to provide a different
> > threshold.
> > 
> > That said, unless someone specifically needs a threshold other than '0', I vote
> > to keep the uAPI as-is and simply exit on every bus lock.
> >  
> 
> According to APM [1],
> "The VMCB provides a Bus Lock Threshold enable bit and an unsigned 16-bit Bus
> Lock Threshold count. On VMRUN, this value is loaded into an internal count
> register. Before the processor executes a bus lock in the guest, it checks
> the value of this register. If the value is greater than 0, the processor
> executes the bus lock successfully and decrements the count. If the value is
> 0, the bus lock is not executed and a #VMEXIT to the VMM is taken."
> 
> So, the bus_lock_counter value "0" always results in VMEXIT_BUSLOCK, so the
> default value of the bus_lock_counter should be greater or equal to "1".

Ugh, so AMD's bus-lock VM-Exit is fault-like.  That's annoying.

> I can remove the module parameter and initialize the value of
> bus_lock_counter as "1" ?

No, because that will have the effect of detecting every other bus lock, whereas
the intent is to detect _every_ bus lock.

I think the only sane approach is to set it to '0' when enabled, and then set it
to '1' on a bus lock exit _before_ exiting to userspace.  If userspace or the
guest mucks with RIP or the guest code stream and doesn't immediately trigger the
bus lock, then so be it.  That only defers the allowed bus lock to a later time,
so effectively such shenanigans would penalize the guest even more.

We'll need to document that KVM on AMD exits to userspace with RIP pointing at
the offending instruction, whereas KVM on Intel exits with RIP pointing at the
instruction after the guilty instruction.

  reply	other threads:[~2024-08-26 16:15 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
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 [this message]
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=ZsyqGGspHOsuyEBY@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox