* [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
@ 2022-08-02 3:32 Chenyi Qiang
2022-08-02 10:51 ` Ingo Molnar
2022-08-02 11:57 ` [tip: x86/urgent] " tip-bot2 for Chenyi Qiang
0 siblings, 2 replies; 5+ messages in thread
From: Chenyi Qiang @ 2022-08-02 3:32 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Tony Luck, Fenghua Yu
Cc: Chenyi Qiang, linux-kernel, x86
It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
this kernel has been kexec'd from a kernel that enabled bus lock
detection.
Disable bus lock detection explicitly if not wanted.
Fixes: ebb1064e7c2e ("x86/traps: Handle #DB for bus lock")
Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
arch/x86/kernel/cpu/intel.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fd5dead8371c..cb796ca6eff5 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1216,22 +1216,23 @@ static void bus_lock_init(void)
{
u64 val;
- /*
- * Warn and fatal are handled by #AC for split lock if #AC for
- * split lock is supported.
- */
- if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT) ||
- (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
- (sld_state == sld_warn || sld_state == sld_fatal)) ||
- sld_state == sld_off)
+ if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
return;
- /*
- * Enable #DB for bus lock. All bus locks are handled in #DB except
- * split locks are handled in #AC in the fatal case.
- */
rdmsrl(MSR_IA32_DEBUGCTLMSR, val);
- val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+
+ if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
+ (sld_state == sld_warn || sld_state == sld_fatal)) ||
+ sld_state == sld_off) {
+ /*
+ * Warn and fatal are handled by #AC for split lock if #AC for
+ * split lock is supported.
+ */
+ val &= ~DEBUGCTLMSR_BUS_LOCK_DETECT;
+ } else {
+ val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+ }
+
wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
2022-08-02 3:32 [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero Chenyi Qiang
@ 2022-08-02 10:51 ` Ingo Molnar
2022-08-02 11:29 ` Chenyi Qiang
2022-08-02 11:57 ` [tip: x86/urgent] " tip-bot2 for Chenyi Qiang
1 sibling, 1 reply; 5+ messages in thread
From: Ingo Molnar @ 2022-08-02 10:51 UTC (permalink / raw)
To: Chenyi Qiang
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Tony Luck, Fenghua Yu, linux-kernel, x86
* Chenyi Qiang <chenyi.qiang@intel.com> wrote:
> It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
> this kernel has been kexec'd from a kernel that enabled bus lock
> detection.
>
> Disable bus lock detection explicitly if not wanted.
Makes sense.
Just curious: in what circumstances does the BIOS/firmware set
DEBUGCTLMSR_BUS_LOCK_DETECT? Does it use it, or does it enable it for some
spurious reason, without really using the feature? (Assuming you are aware
of instances where this happened - or was this simply a hypothetical?)
Thanks,
Ingo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
2022-08-02 10:51 ` Ingo Molnar
@ 2022-08-02 11:29 ` Chenyi Qiang
2022-08-02 11:42 ` Ingo Molnar
0 siblings, 1 reply; 5+ messages in thread
From: Chenyi Qiang @ 2022-08-02 11:29 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Tony Luck, Fenghua Yu, linux-kernel, x86
On 8/2/2022 6:51 PM, Ingo Molnar wrote:
>
> * Chenyi Qiang <chenyi.qiang@intel.com> wrote:
>
>> It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
>> this kernel has been kexec'd from a kernel that enabled bus lock
>> detection.
>>
>> Disable bus lock detection explicitly if not wanted.
>
> Makes sense.
>
> Just curious: in what circumstances does the BIOS/firmware set
> DEBUGCTLMSR_BUS_LOCK_DETECT? Does it use it, or does it enable it for some
> spurious reason, without really using the feature? (Assuming you are aware
> of instances where this happened - or was this simply a hypothetical?)
Yes, It's just a hypothetical for BIOS/firmware. Kexec is the real case
I met with this problem.
>
> Thanks,
>
> Ingo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
2022-08-02 11:29 ` Chenyi Qiang
@ 2022-08-02 11:42 ` Ingo Molnar
0 siblings, 0 replies; 5+ messages in thread
From: Ingo Molnar @ 2022-08-02 11:42 UTC (permalink / raw)
To: Chenyi Qiang
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Tony Luck, Fenghua Yu, linux-kernel, x86
* Chenyi Qiang <chenyi.qiang@intel.com> wrote:
>
>
> On 8/2/2022 6:51 PM, Ingo Molnar wrote:
> >
> > * Chenyi Qiang <chenyi.qiang@intel.com> wrote:
> >
> > > It's possible that BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT, or
> > > this kernel has been kexec'd from a kernel that enabled bus lock
> > > detection.
> > >
> > > Disable bus lock detection explicitly if not wanted.
> >
> > Makes sense.
> >
> > Just curious: in what circumstances does the BIOS/firmware set
> > DEBUGCTLMSR_BUS_LOCK_DETECT? Does it use it, or does it enable it for some
> > spurious reason, without really using the feature? (Assuming you are aware
> > of instances where this happened - or was this simply a hypothetical?)
>
> Yes, It's just a hypothetical for BIOS/firmware. Kexec is the real case I
> met with this problem.
Fair enough, I've tweaked the changelog a bit to de-emphasize the firmware
angle, and applied your fix to tip:x86/urgent.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 5+ messages in thread
* [tip: x86/urgent] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
2022-08-02 3:32 [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero Chenyi Qiang
2022-08-02 10:51 ` Ingo Molnar
@ 2022-08-02 11:57 ` tip-bot2 for Chenyi Qiang
1 sibling, 0 replies; 5+ messages in thread
From: tip-bot2 for Chenyi Qiang @ 2022-08-02 11:57 UTC (permalink / raw)
To: linux-tip-commits; +Cc: Chenyi Qiang, Ingo Molnar, Tony Luck, x86, linux-kernel
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ffa6482e461ff550325356ae705b79e256702ea9
Gitweb: https://git.kernel.org/tip/ffa6482e461ff550325356ae705b79e256702ea9
Author: Chenyi Qiang <chenyi.qiang@intel.com>
AuthorDate: Tue, 02 Aug 2022 11:32:06 +08:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Tue, 02 Aug 2022 13:42:00 +02:00
x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero
It's possible that this kernel has been kexec'd from a kernel that
enabled bus lock detection, or (hypothetically) BIOS/firmware has set
DEBUGCTLMSR_BUS_LOCK_DETECT.
Disable bus lock detection explicitly if not wanted.
Fixes: ebb1064e7c2e ("x86/traps: Handle #DB for bus lock")
Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20220802033206.21333-1-chenyi.qiang@intel.com
---
arch/x86/kernel/cpu/intel.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 663f6e6..2d7ea54 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1216,22 +1216,23 @@ static void bus_lock_init(void)
{
u64 val;
- /*
- * Warn and fatal are handled by #AC for split lock if #AC for
- * split lock is supported.
- */
- if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT) ||
- (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
- (sld_state == sld_warn || sld_state == sld_fatal)) ||
- sld_state == sld_off)
+ if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
return;
- /*
- * Enable #DB for bus lock. All bus locks are handled in #DB except
- * split locks are handled in #AC in the fatal case.
- */
rdmsrl(MSR_IA32_DEBUGCTLMSR, val);
- val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+
+ if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
+ (sld_state == sld_warn || sld_state == sld_fatal)) ||
+ sld_state == sld_off) {
+ /*
+ * Warn and fatal are handled by #AC for split lock if #AC for
+ * split lock is supported.
+ */
+ val &= ~DEBUGCTLMSR_BUS_LOCK_DETECT;
+ } else {
+ val |= DEBUGCTLMSR_BUS_LOCK_DETECT;
+ }
+
wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
}
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-08-02 11:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-02 3:32 [RESEND] x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero Chenyi Qiang
2022-08-02 10:51 ` Ingo Molnar
2022-08-02 11:29 ` Chenyi Qiang
2022-08-02 11:42 ` Ingo Molnar
2022-08-02 11:57 ` [tip: x86/urgent] " tip-bot2 for Chenyi Qiang
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.