Received: by 10.223.185.116 with SMTP id b49csp3275756wrg; Sun, 25 Feb 2018 18:41:44 -0800 (PST) X-Google-Smtp-Source: AH8x226hNpk37oEJTvkWCrql/Q+5ZpbHsc/rwb7KeGpWt9zg8y0JuNqgNqjGt2ZQz37xsZF4emqu X-Received: by 2002:a17:902:523:: with SMTP id 32-v6mr9031052plf.145.1519612904722; Sun, 25 Feb 2018 18:41:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519612904; cv=none; d=google.com; s=arc-20160816; b=0G/5tX5T7VNc8/13DEFMH+3wQP5kWZAqhsYzARxMjECPB+2RSxKN6rp88EJFdQ7YpR xu7HOXSPLeP5sgQ23cnFt899Ga2GWljwUxuxAmwGoImtP+r0MXacDpQgJXh0TYGpm+mW 0dveB+bhxRdzdz/D1vgOlVgKc4Y8khzaoyulOn3K+z4q5MnWzIb14tnOGe+Ji/nqbfGY YYIpCCgllha1CjYtQpW8bYQzcRUa8OcQVvDsdxRklsWI25Kr8W9sdu6e4ui3tsNsB/BB eXs52na4Dk/BwFkZFNa0fRDn7txCeP/n3qfk6bri4wYYUZMA22za/pwhsHgIJBQ5SyJQ DIBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=AblzpnS1JDNsBXHZKYfn2PeRj+tD/7k+GEciotzFM3M=; b=WwFI3OPebY87tZBIcecgRDOYDEDk8mzBfWgMfHbsfORfWFIQ/lnTGzyA9aQa6qRK41 t9RxGWJ7fN7z2MpxVFVNJSV3HirtmzXLj2hM1LddFF5tGNxMWi0MJC1x6RSZMAoygd2d HrJAS9TR8Vrl1FGoTg4dPldES04Z4/Eccr+ypx0FyERRxLM2wTO4W4vznqN3nRdTdnNz YPtNZeAWcigrcL+ZVXvVo9vmKJdTk8ArPND/fysLcB3/wKijnEGMkh70Bv5zjHErs7ol XC797XxSp+vANCLGIgjsH1comRaaasfsh13C+i8BnqNL8ff/u6Ud+BSeutJZyoI1TXQb hhIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m26si4921014pgc.438.2018.02.25.18.41.30; Sun, 25 Feb 2018 18:41:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752054AbeBZCkq (ORCPT + 99 others); Sun, 25 Feb 2018 21:40:46 -0500 Received: from mail.cn.fujitsu.com ([183.91.158.132]:1912 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751931AbeBZCkp (ORCPT ); Sun, 25 Feb 2018 21:40:45 -0500 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="37246183" Received: from bogon (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 26 Feb 2018 10:40:43 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 28AC54B31486; Mon, 26 Feb 2018 10:40:42 +0800 (CST) Received: from localhost.localdomain (10.167.226.106) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 26 Feb 2018 10:40:42 +0800 From: Dou Liyang To: , CC: , , , , , Dou Liyang Subject: [PATCH v4 1/2] x86/apic: Move pending intr check code into it's own function Date: Mon, 26 Feb 2018 10:39:56 +0800 Message-ID: <20180226023957.22861-1-douly.fnst@cn.fujitsu.com> X-Mailer: git-send-email 2.14.3 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 28AC54B31486.A000D X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org the pending interrupt check code is mixed with the local APIC setup code, that looks messy. Extract the related code, move it into a new function named apic_pending_intr_clear(). Signed-off-by: Dou Liyang --- arch/x86/kernel/apic/apic.c | 98 ++++++++++++++++++++++++--------------------- 1 file changed, 52 insertions(+), 46 deletions(-) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 84b244ec49ed..be223ebd1bb3 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1408,6 +1408,56 @@ static void lapic_setup_esr(void) oldvalue, value); } +static void apic_pending_intr_clear(void) +{ + long long max_loops = cpu_khz ? cpu_khz : 1000000; + unsigned long long tsc = 0, ntsc; + unsigned int value, queued; + int i, j, acked = 0; + + if (boot_cpu_has(X86_FEATURE_TSC)) + tsc = rdtsc(); + /* + * After a crash, we no longer service the interrupts and a pending + * interrupt from previous kernel might still have ISR bit set. + * + * Most probably by now CPU has serviced that pending interrupt and + * it might not have done the ack_APIC_irq() because it thought, + * interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it + * does not clear the ISR bit and cpu thinks it has already serivced + * the interrupt. Hence a vector might get locked. It was noticed + * for timer irq (vector 0x31). Issue an extra EOI to clear ISR. + */ + do { + queued = 0; + for (i = APIC_ISR_NR - 1; i >= 0; i--) + queued |= apic_read(APIC_IRR + i*0x10); + + for (i = APIC_ISR_NR - 1; i >= 0; i--) { + value = apic_read(APIC_ISR + i*0x10); + for (j = 31; j >= 0; j--) { + if (value & (1< 256) { + printk(KERN_ERR "LAPIC pending interrupts after %d EOI\n", + acked); + break; + } + if (queued) { + if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) { + ntsc = rdtsc(); + max_loops = (cpu_khz << 10) - (ntsc - tsc); + } else + max_loops--; + } + } while (queued && max_loops > 0); + WARN_ON(max_loops <= 0); +} + /** * setup_local_APIC - setup the local APIC * @@ -1417,13 +1467,7 @@ static void lapic_setup_esr(void) static void setup_local_APIC(void) { int cpu = smp_processor_id(); - unsigned int value, queued; - int i, j, acked = 0; - unsigned long long tsc = 0, ntsc; - long long max_loops = cpu_khz ? cpu_khz : 1000000; - - if (boot_cpu_has(X86_FEATURE_TSC)) - tsc = rdtsc(); + unsigned int value; if (disable_apic) { disable_ioapic_support(); @@ -1475,45 +1519,7 @@ static void setup_local_APIC(void) value &= ~APIC_TPRI_MASK; apic_write(APIC_TASKPRI, value); - /* - * After a crash, we no longer service the interrupts and a pending - * interrupt from previous kernel might still have ISR bit set. - * - * Most probably by now CPU has serviced that pending interrupt and - * it might not have done the ack_APIC_irq() because it thought, - * interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it - * does not clear the ISR bit and cpu thinks it has already serivced - * the interrupt. Hence a vector might get locked. It was noticed - * for timer irq (vector 0x31). Issue an extra EOI to clear ISR. - */ - do { - queued = 0; - for (i = APIC_ISR_NR - 1; i >= 0; i--) - queued |= apic_read(APIC_IRR + i*0x10); - - for (i = APIC_ISR_NR - 1; i >= 0; i--) { - value = apic_read(APIC_ISR + i*0x10); - for (j = 31; j >= 0; j--) { - if (value & (1< 256) { - printk(KERN_ERR "LAPIC pending interrupts after %d EOI\n", - acked); - break; - } - if (queued) { - if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) { - ntsc = rdtsc(); - max_loops = (cpu_khz << 10) - (ntsc - tsc); - } else - max_loops--; - } - } while (queued && max_loops > 0); - WARN_ON(max_loops <= 0); + apic_pending_intr_clear(); /* * Now that we are all set up, enable the APIC -- 2.14.3