stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shaohua Li <shli@fb.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>, <Kernel-team@fb.com>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, <stable@vger.kernel.org>,
	<lenb@kernel.org>, <fenghua.yu@intel.com>
Subject: Re: [PATCH] x86: serialize LVTT and TSC_DEADLINE write
Date: Tue, 8 Sep 2015 21:13:54 -0700	[thread overview]
Message-ID: <20150909041352.GA2059853@devbig257.prn2.facebook.com> (raw)
In-Reply-To: <20150909033937.GH4524@tassilo.jf.intel.com>

On Tue, Sep 08, 2015 at 08:39:37PM -0700, Andi Kleen wrote:
> > Hmm, I didn't mean mfence can't serialize the instructions. For a true
> > IO, a serialization can't guarantee device finishes the IO, we generally
> > read some safe IO registers to wait IO finish. I completely don't know
> > if this case fits here though.
> 
> Sorry for the late answer. We (Intel) analyzed this case in detail and
> can confirm that the following sequence
> 
> 1.   Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
> 23. MFENCE.
> 4.   WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline.
> 
> has the same effect as the loop algorithm described in the SDM on all Intel
> CPUs. So it's fine to use MFENCE here.

Thank you very much, Andi!

Here is the updated patch.


>From b5cdd3c14b0589e5d5a72d607814d9e808d05765 Mon Sep 17 00:00:00 2001
Message-Id: <b5cdd3c14b0589e5d5a72d607814d9e808d05765.1441771848.git.shli@fb.com>
From: Shaohua Li <shli@fb.com>
Date: Thu, 30 Jul 2015 16:24:43 -0700
Subject: [PATCH] x86: serialize LVTT and TSC_DEADLINE write

We saw a strange issue with local APIC timer. Some random CPU doesn't
receive any local APIC timer interrupt, which causes different issues.
The cpu uses TSC-Deadline mode for local APIC timer and APIC is in xAPIC
mode. When this happens, manually writing TSC_DEADLINE MSR can trigger
interrupt again and the system goes normal.

Currently we only see this issue in E5-2660 v2 and E5-2680 v2 CPU.
Compiler version seems mattering too, it's quite easy to reproduce the
issue with v4.7 gcc.

Since the local APIC timer interrupt number is 0, we either lose the
first interrupt or TSC_DEADLINE MSR isn't set correctly. After some
debugging, we believe it's the serialize issue described in Intel SDM.
In xAPIC mode, write to APIC LVTT and write to TSC_DEADLINE isn't
serialized. Debug shows read TSC_DEADLINE MSR followed the very first
MSR write returns 0 in the buggy cpu.

Thanks Andi Kleen confirms a 'mfence' can do the serialization here.
'mfence' instruction should be supported by CPU with TSC_DEADLINE, so we
don't need to check the instruction availability.

Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: stable@vger.kernel.org v3.7+
Signed-off-by: Shaohua Li <shli@fb.com>
---
 arch/x86/kernel/apic/apic.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 3ca3e46..e3fd4ab 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -336,6 +336,13 @@ static void __setup_APIC_LVTT(unsigned int clocks, int oneshot, int irqen)
 	apic_write(APIC_LVTT, lvtt_value);
 
 	if (lvtt_value & APIC_LVT_TIMER_TSCDEADLINE) {
+		/*
+		 * See Intel SDM: TSC-Deadline Mode chapter. In xAPIC mode,
+		 * writing APIC LVTT and TSC_DEADLINE MSR isn't serialized.
+		 * According to Intel, mfence can do the serialization here.
+		 * */
+		asm volatile("mfence" : : : "memory");
+
 		printk_once(KERN_DEBUG "TSC deadline timer enabled\n");
 		return;
 	}
-- 
1.8.1


  reply	other threads:[~2015-09-09  4:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 22:11 [PATCH] x86: serialize LVTT and TSC_DEADLINE write Shaohua Li
2015-08-01 10:10 ` Thomas Gleixner
2015-08-02 15:49   ` Shaohua Li
2015-08-02 19:41     ` Thomas Gleixner
2015-08-03 23:58       ` Shaohua Li
2015-08-05  8:44         ` Ingo Molnar
2015-08-05 16:25           ` Shaohua Li
2015-09-09  3:39             ` Andi Kleen
2015-09-09  4:13               ` Shaohua Li [this message]
2015-09-09  7:35               ` Thomas Gleixner

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150909041352.GA2059853@devbig257.prn2.facebook.com \
    --to=shli@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=ak@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).