[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d4531d9-3a61-ecf2-5a43-2cc03f013a62@amd.com>
Date: Mon, 15 Jul 2024 10:11:05 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Ravi Bangoria <ravi.bangoria@....com>, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
seanjc@...gle.com, pbonzini@...hat.com
Cc: hpa@...or.com, rmk+kernel@...linux.org.uk, peterz@...radead.org,
james.morse@....com, lukas.bulwahn@...il.com, arjan@...ux.intel.com,
j.granados@...sung.com, sibs@...natelecom.cn, nik.borisov@...e.com,
michael.roth@....com, nikunj.dadhania@....com, babu.moger@....com,
x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
santosh.shukla@....com, ananth.narayan@....com, sandipan.das@....com,
manali.shukla@....com, jmattson@...gle.com
Subject: Re: [PATCH v2 0/4] x86/cpu: Add Bus Lock Detect support for AMD
On 7/12/24 04:39, Ravi Bangoria wrote:
> Upcoming AMD uarch will support Bus Lock Detect (called Bus Lock Trap
Saying "Upcoming AMD uarch" is ok in the cover letter, but in a commit
message it doesn't mean a lot when viewed a few years from now. I would
just word it as, depending on the context, something like "AMD
processors that support Bus Lock Detect ..." or "AMD processors support
Bus Lock Detect ...".
Since it looks like a v2 will be needed to address the kernel test robot
issues, maybe re-work your commit messages.
Thanks,
Tom
> in AMD docs). Add support for the same in Linux. Bus Lock Detect is
> enumerated with cpuid CPUID Fn0000_0007_ECX_x0 bit [24 / BUSLOCKTRAP].
> It can be enabled through MSR_IA32_DEBUGCTLMSR. When enabled, hardware
> clears DR6[11] and raises a #DB exception on occurrence of Bus Lock if
> CPL > 0. More detail about the feature can be found in AMD APM[1].
>
> Patches are prepared on tip/master (a6fffa92da54).
>
> [1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
> 2023, Vol 2, 13.1.3.6 Bus Lock Trap
> https://bugzilla.kernel.org/attachment.cgi?id=304653
>
> v1: https://lore.kernel.org/r/20240429060643.211-1-ravi.bangoria@amd.com
> v1->v2:
> - Call bus_lock_init() from common.c. Although common.c is shared across
> all X86_VENDOR_*, bus_lock_init() internally checks for
> X86_FEATURE_BUS_LOCK_DETECT, hence it's safe to call it from common.c.
> - s/split-bus-lock.c/bus_lock.c/ for a new filename.
> - Add a KVM patch to disable Bus Lock Trap unconditionally when SVM
> support is missing.
>
> Note:
> A Qemu fix is also require to handle corner case where a hardware
> instruction or data breakpoint is created by Qemu remote debugger (gdb)
> on the same instruction which also causes a Bus Lock. I'll post a Qemu
> patch separately.
>
> Ravi Bangoria (4):
> x86/split_lock: Move Split and Bus lock code to a dedicated file
> x86/bus_lock: Add support for AMD
> KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM support is
> missing
> KVM: SVM: Add Bus Lock Detect support
>
> arch/x86/include/asm/cpu.h | 4 +
> arch/x86/kernel/cpu/Makefile | 1 +
> arch/x86/kernel/cpu/bus_lock.c | 406 ++++++++++++++++++++++++++++++++
> arch/x86/kernel/cpu/common.c | 2 +
> arch/x86/kernel/cpu/intel.c | 407 ---------------------------------
> arch/x86/kvm/svm/nested.c | 3 +-
> arch/x86/kvm/svm/svm.c | 16 +-
> 7 files changed, 430 insertions(+), 409 deletions(-)
> create mode 100644 arch/x86/kernel/cpu/bus_lock.c
>
Powered by blists - more mailing lists