From: Fenghua Yu <email@example.com>
To: "Thomas Gleixner" <firstname.lastname@example.org>,
"Borislav Petkov" <email@example.com>,
"Ingo Molnar" <firstname.lastname@example.org>,
"Peter Zijlstra" <email@example.com>,
"Randy Dunlap" <firstname.lastname@example.org>,
"Tony Luck" <email@example.com>,
"Christopherson Sean J" <firstname.lastname@example.org>,
"Ashok Raj" <email@example.com>,
"Ravi V Shankar" <firstname.lastname@example.org>
Cc: "linux-kernel" <email@example.com>,
"x86" <firstname.lastname@example.org>, Fenghua Yu <email@example.com>
Subject: [PATCH RFC v3 0/4] x86/bus_lock: Enable bus lock detection
Date: Sat, 31 Oct 2020 00:27:10 +0000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
A bus lock  is acquired either through split locked access to
writeback (WB) memory or by using locks to uncacheable (UC) memory
(e.g. direct device assignment). This is typically >1000 cycles slower
than an atomic operation within a cache line. It also disrupts performance
on other cores.
Although split lock can be detected by #AC trap, the trap is triggered
before the instruction acquires bus lock. This makes it difficult to
mitigate bus lock (e.g. throttle the user application).
Some CPUs have ability to notify the kernel by an #DB trap after a user
instruction acquires a bus lock and is executed. This allows the kernel
to enforce user application throttling or mitigations.
#DB for bus lock detect fixes issues in #AC for split lock detect:
1) It's architectural ... just need to look at one CPUID bit to know it
2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread.
So each process or guest can have different behavior.
3) It has support for VMM/guests (new VMEXIT codes, etc).
Hardware only generates #DB for bus lock detect when CPL>0 to avoid
nested #DB from multiple bus locks while the first #DB is being handled.
Use the existing kernel command line option "split_lock_detect=" to handle
#DB for bus lock:
#AC for split lock #DB for bus lock
off Do nothing Do nothing
warn Kernel OOPs Warn once per task and
Warn once per task and and continues to run.
disable future checking When both features are
supported, warn in #DB
fatal Kernel OOPs Send SIGBUS to user
Send SIGBUS to user
When both features are
supported, fatal in #AC.
ratelimit:N Do nothing Limit bus lock rate to
N per second in the
current non root user.
Default split_lock_detect is "warn".
 Chapter 8 https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
- Remove DR6_RESERVED change (PeterZ).
- Simplify the documentation (Randy).
- Architecture changed based on feedback from Thomas and PeterZ. #DB is
no longer generated for bus lock in ring0.
- Split the one single patch into four patches.
[RFC v1 can be found at: https://email@example.com/]
Fenghua Yu (4):
x86/cpufeatures: Enumerate #DB for bus lock detection
x86/bus_lock: Handle warn and fatal in #DB for bus lock
x86/bus_lock: Set rate limit for bus lock
Documentation/admin-guide: Change doc for split_lock_detect parameter
.../admin-guide/kernel-parameters.txt | 28 +++-
arch/x86/include/asm/cpu.h | 10 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/include/uapi/asm/debugreg.h | 1 +
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/intel.c | 145 +++++++++++++++---
arch/x86/kernel/traps.c | 7 +
include/linux/sched/user.h | 4 +-
kernel/user.c | 7 +
10 files changed, 176 insertions(+), 30 deletions(-)
next reply other threads:[~2020-10-31 0:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 0:27 Fenghua Yu [this message]
2020-10-31 0:27 ` [PATCH RFC v3 1/4] x86/cpufeatures: Enumerate #DB for bus lock detection Fenghua Yu
2020-10-31 0:27 ` [PATCH RFC v3 2/4] x86/bus_lock: Handle warn and fatal in #DB for bus lock Fenghua Yu
2020-11-03 12:15 ` Xiaoyao Li
2020-11-06 20:31 ` Fenghua Yu
2020-10-31 0:27 ` [PATCH RFC v3 3/4] x86/bus_lock: Set rate limit " Fenghua Yu
2020-10-31 0:27 ` [PATCH RFC v3 4/4] Documentation/admin-guide: Change doc for split_lock_detect parameter Fenghua Yu
2020-10-31 3:14 ` Randy Dunlap
2020-11-02 17:03 ` Fenghua Yu
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).