All of lore.kernel.org
 help / color / mirror / Atom feed
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").

  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 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.