From: Sean Christopherson <seanjc@google.com>
To: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, pbonzini@redhat.com,
thomas.lendacky@amd.com, hpa@zytor.com,
rmk+kernel@armlinux.org.uk, peterz@infradead.org,
james.morse@arm.com, lukas.bulwahn@gmail.com,
arjan@linux.intel.com, j.granados@samsung.com,
sibs@chinatelecom.cn, nik.borisov@suse.com,
michael.roth@amd.com, nikunj.dadhania@amd.com,
babu.moger@amd.com, x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, santosh.shukla@amd.com,
ananth.narayan@amd.com, sandipan.das@amd.com
Subject: Re: [PATCH 3/3] KVM SVM: Add Bus Lock Detect support
Date: Wed, 5 Jun 2024 08:08:54 -0700 [thread overview]
Message-ID: <ZmB_hl7coZ_8KA8Q@google.com> (raw)
In-Reply-To: <e1c29dd4-2eb9-44fe-abf2-f5ca0e84e2a6@amd.com>
On Wed, Jun 05, 2024, Ravi Bangoria wrote:
> Hi Sean,
>
> On 6/4/2024 6:15 AM, Sean Christopherson wrote:
> > On Mon, Apr 29, 2024, Ravi Bangoria wrote:
> >> Upcoming AMD uarch will support Bus Lock Detect. Add support for it
> >> in KVM. Bus Lock Detect is enabled through MSR_IA32_DEBUGCTLMSR and
> >> MSR_IA32_DEBUGCTLMSR is virtualized only if LBR Virtualization is
> >> enabled. Add this dependency in the KVM.
> >
> > This is woefully incomplete, e.g. db_interception() needs to be updated to decipher
> > whether the #DB is the responsbility of the host or of the guest.
>
> Can you please elaborate. Are you referring to vcpu->guest_debug thingy?
Yes. More broadly, all of db_interception().
> > Honestly, I don't see any point in virtualizing this in KVM. As Jim alluded to,
> > what's far, far more interesting for KVM is "Bus Lock Threshold". Virtualizing
> > this for the guest would have been nice to have during the initial split-lock #AC
> > support, but now I'm skeptical the complexity is worth the payoff.
>
> This has a valid usecase of penalizing offending processes. I'm not sure
> how much it's really used in the production though.
Yeah, but split-lock #AC and #DB have existed on Intel for years, and no one has
put in the effort to land KVM support, despite the series getting as far as v9[*].
Some of the problems on Intel were due to the awful FMS-based feature detection,
but those weren't the only hiccups. E.g. IIRC, we never sorted out what should
happen if both the host and guest want bus-lock #DBs.
Anyways, my point is that, except for SEV-ES+ where there's no good reason NOT to
virtualize Bus Lock Detect, I'm not convinced that it's worth virtualizing bus-lock
#DBs.
[*] https://lore.kernel.org/all/20200509110542.8159-1-xiaoyao.li@intel.com
> > I suppose we could allow it if #DB isn't interecepted, at which point the enabling
> > required is minimal?
>
> The feature uses DEBUG_CTL MSR, #DB and DR6 register. Do you mean expose
> it when all three are accelerated or just #DB?
I mean that if KVM isn't intercepting #DB, then there's no extra complexity needed
to sort out whether the #DB "belongs" to the host or the guest. See commit
90cbf6d914ad ("KVM: SEV-ES: Eliminate #DB intercept when DebugSwap enabled").
next prev parent reply other threads:[~2024-06-05 15:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 6:06 [PATCH 0/3] x86/cpu: Add Bus Lock Detect support for AMD Ravi Bangoria
2024-04-29 6:06 ` [PATCH 1/3] x86/split_lock: Move Split and Bus lock code to a dedicated file Ravi Bangoria
2024-05-06 12:58 ` Borislav Petkov
2024-05-07 4:07 ` Ravi Bangoria
2024-04-29 6:06 ` [PATCH 2/3] x86/bus_lock: Add support for AMD Ravi Bangoria
2024-05-06 16:05 ` Tom Lendacky
2024-05-07 4:08 ` Ravi Bangoria
2024-05-06 16:24 ` Jim Mattson
2024-05-07 3:57 ` Ravi Bangoria
2024-04-29 6:06 ` [PATCH 3/3] KVM SVM: Add Bus Lock Detect support Ravi Bangoria
2024-06-04 0:45 ` Sean Christopherson
2024-06-05 11:38 ` Ravi Bangoria
2024-06-05 15:08 ` Sean Christopherson [this message]
2024-06-05 16:14 ` Ravi Bangoria
2024-06-12 1:42 ` Sean Christopherson
2024-07-10 2:25 ` Ravi Bangoria
2024-07-10 4:15 ` Jim Mattson
2024-07-10 13:52 ` Sean Christopherson
2024-07-11 8:51 ` Ravi Bangoria
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=ZmB_hl7coZ_8KA8Q@google.com \
--to=seanjc@google.com \
--cc=ananth.narayan@amd.com \
--cc=arjan@linux.intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=j.granados@samsung.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=sandipan.das@amd.com \
--cc=santosh.shukla@amd.com \
--cc=sibs@chinatelecom.cn \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox