From: Manali Shukla <manali.shukla@amd.com>
To: Sean Christopherson <seanjc@google.com>
Cc: <pbonzini@redhat.com>, <mingo@redhat.com>, <bp@alien8.de>,
<kvm@vger.kernel.org>, <x86@kernel.org>,
<nikunj.dadhania@amd.com>, <Naveen.Rao@amd.com>,
<ravi.bangoria@amd.com>, <peterz@infradead.org>,
<dave.hansen@linux.intel.com>, <tglx@kernel.org>
Subject: Re: [RFC PATCH v1] x86/split_lock: Provide KVM helper to log guest bus lock exits
Date: Wed, 8 Apr 2026 10:39:26 +0530 [thread overview]
Message-ID: <04a522a6-fbbe-42e0-8395-a9b74968b8be@amd.com> (raw)
In-Reply-To: <acwFolDAoqlY2ok8@google.com>
On 3/31/2026 11:04 PM, Sean Christopherson wrote:
> On Tue, Mar 24, 2026, Manali Shukla wrote:
>> The intent is purely observational — give hypervisor owners
>> visibility into which guest is generating bus locks so they can act
>> accordingly. No policy enforcement is done in the kernel. Suggestions
>> on the approach are welcome.
>
> This makes no sense. KVM is exiting to userspace, the hypervisor owner doesn't
> need to grep dmesg to understand *exactly* what vCPU is generating bus locks.
I agree that the VMM receives KVM_EXIT_X86_BUS_LOCK and knows which vCPU
caused it, and I am fine with that approach. However, this request came
from a customer who wanted to know which guest is causing bus locks at
which RIP in dmesg, similar to how split lock detection on Intel does
it. I am trying to address that use case.
-Manali
next prev parent reply other threads:[~2026-04-08 5:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 12:40 [RFC PATCH v1] x86/split_lock: Provide KVM helper to log guest bus lock exits Manali Shukla
2026-03-24 18:04 ` Borislav Petkov
2026-03-25 9:32 ` Manali Shukla
2026-03-25 9:54 ` Borislav Petkov
2026-03-31 17:34 ` Sean Christopherson
2026-04-08 5:09 ` Manali Shukla [this message]
2026-04-09 20:56 ` Sean Christopherson
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=04a522a6-fbbe-42e0-8395-a9b74968b8be@amd.com \
--to=manali.shukla@amd.com \
--cc=Naveen.Rao@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/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.