Message ID | 20240712093943.1288-1-ravi.bangoria@amd.com (mailing list archive) |
---|---|
Headers | show |
Series | x86/cpu: Add Bus Lock Detect support for AMD | expand |
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 >
On 15-Jul-24 8:41 PM, Tom Lendacky wrote: > 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. Makes sense. Will reword it in v3. Thanks, Ravi