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