Received: by 10.223.185.116 with SMTP id b49csp387747wrg; Thu, 22 Feb 2018 23:55:53 -0800 (PST) X-Google-Smtp-Source: AH8x226NM0DdbVL4mUNH29Ec5NblzuqO7QR2ke6jKObyN5rLhlW6s3vboNkEBn8vArwl84VIqmjE X-Received: by 10.101.71.141 with SMTP id e13mr755652pgs.438.1519372553706; Thu, 22 Feb 2018 23:55:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519372553; cv=none; d=google.com; s=arc-20160816; b=Um8+xueVsV342iel9gHJLVJDGfy1wdTCfdtkKvcdop5ZzkrSPN1JM5eF1lv8lRWtNN dMPQseWXO0vYpcOL4N2+KsjmQH9K/f363hAKMfBf4EyoBWKXVuDtKBvrAJ8FUEltlTF+ zm+WGD0UuUFNr8qmDWB06QHFQ9Yq1YoDIZCUN4B7JUHf26YMgsEakkQSh68dP+gwkFka KKw0EbHvPPU1NSdMqBsaXUK4IVDJt9sreHObT3JIqF2/JZ5XqTLqv/B4MRo3knb6hVUc UX8EKC9xlUDPSfPaYS/WDcjc7+RkfrNI96jM0/m6FUQGmNFxcUtMttoo7pfMVNUiOI7w OUgg== 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=uq/wp5yMsgTfyNqA95mFuq5UH1pbGrGTOQy2SvGL2dFIVJX/C2+Jy4hLZwTIhdsKFB Ic7pSrF8EhIba2d/CG/x1ByXU3IFMs/mCQixlErQmqm/QxoCV/O63VUu81qj6eXWfDqk S5v3a6euIwVLorWih5JvBMbschXP6yZw774uGvxxPdzuMrVADQT3XSu1jkY5kVBix9uP vCKloX/wjqhGBOILnzA4VqCLgiYG+MBn3PwcG/D+pPSHTTekfezABbrD+hCnSfFegnOr vg1Gu37zTHtmRucBpNIfNKyEW9QGV771JArLTDdId4QDxg4HWNBY5CoYFyAfvm80PNL+ b+7w== 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 e17-v6si1470980plj.334.2018.02.22.23.55.39; Thu, 22 Feb 2018 23:55:53 -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 S1751416AbeBWHy4 (ORCPT + 99 others); Fri, 23 Feb 2018 02:54:56 -0500 Received: from mail.cn.fujitsu.com ([183.91.158.132]:11991 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750796AbeBWHyy (ORCPT ); Fri, 23 Feb 2018 02:54:54 -0500 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="37192424" Received: from bogon (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 23 Feb 2018 15:54:50 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 3163848AE761; Fri, 23 Feb 2018 15:54:48 +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; Fri, 23 Feb 2018 15:54:48 +0800 From: Dou Liyang To: , CC: , , , , , Dou Liyang Subject: [PATCH v3 1/2] x86/apic: Move pending intr check code into it's own function Date: Fri, 23 Feb 2018 15:54:29 +0800 Message-ID: <20180223075430.12395-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: 3163848AE761.A04FB 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