Received: by 10.223.176.46 with SMTP id f43csp680566wra; Fri, 19 Jan 2018 00:08:24 -0800 (PST) X-Google-Smtp-Source: ACJfBosJp177K3yTYX86h2ZQs3FvpqqEjRg68D6B4ezrMzy2khwxe+Wme9h7u83xrsVhe2Bh5yDl X-Received: by 2002:a17:902:4483:: with SMTP id l3-v6mr1156028pld.382.1516349304666; Fri, 19 Jan 2018 00:08:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516349304; cv=none; d=google.com; s=arc-20160816; b=rnuBRY6VOPStvlAC0jGqCyunQhbbeIyUtjWEn/YFxmNpKHmqC/S77usNRaCWnqsDuX noSB9CQAg00837TJqPkgEb9Lv9mCGZEft78y52MPFlI1hAdYe0suqX4gN3LPDUs+eDQW JfUCbN0o2J628cMhYElEdajRSmPXRdlIQ/UttEr/tKqFkC6FFr2AWfTBTDZOlH2HYKI3 J6YMBbQ9Gsdc0k+0ai1QnD80mkTc7Xl5xsxDhuqjso6bGHucdxbPh5oXU8FK8t2v2724 w3guuXVvoNjfJ9pN2qOnk8w7LcxuIcxsimH6CDgcpemhaJ4JcaY7+A4WFHzBLVT93cS+ ykEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=f9ScZYjfJeMhKagJYzDV8+eHWk5H/MzxO4Ywf3J6BUA=; b=gHC7icR9zXLkIPHQ8Pl/fYT+XLjDoIMVJ7lC3KPU4kCKPzvyqjV0YthRTHUj+XBURT FaMPW5d1DWwthaboNGdt7EDG6+WcGc+fZKmcDpKYkW7H6eSHYffEdOvQhz033QdGp/g9 /ULCOLleCFTT7gAZA2m+iBirfzkAa69msexURMC/ERxSpjFfzF9MiW2yhtoMYv1xGP72 JvVVOMEKnHpXW5vVgSv0tAR+pfZxk2J0/nHKpNlZI9G0DuzUDQHVJJzu0eDpPAAXvi6V 6Go1cxXhIy7TraxILntsMeriokigbV8Q4UOGiDE2Mrhp61Dh3duU591PSfvU0oq44IQr 3AeA== 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 d25si8845936pfl.211.2018.01.19.00.08.10; Fri, 19 Jan 2018 00:08:24 -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 S1754777AbeASIHR (ORCPT + 99 others); Fri, 19 Jan 2018 03:07:17 -0500 Received: from mail.cn.fujitsu.com ([183.91.158.132]:8793 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751548AbeASIHD (ORCPT ); Fri, 19 Jan 2018 03:07:03 -0500 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="35484480" Received: from bogon (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 19 Jan 2018 16:06:59 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 6F41148AEA17; Fri, 19 Jan 2018 16:06:59 +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, 19 Jan 2018 16:06:59 +0800 Subject: Re: [RESEND PATCH 3/3] x86/apic: Clean up the names of legacy irq mode setting related functions To: Baoquan He CC: , , , , , , , , , References: <1515123732-28908-1-git-send-email-bhe@redhat.com> <20180105043929.GL7235@x1> <20180119072130.GG1753@localhost.localdomain> From: Dou Liyang Message-ID: Date: Fri, 19 Jan 2018 16:06:57 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180119072130.GG1753@localhost.localdomain> Content-Type: text/plain; charset="gbk"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 6F41148AEA17.AB0D4 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 At 01/19/2018 03:21 PM, Baoquan He wrote: > On 01/19/18 at 02:42pm, Dou Liyang wrote: >> Hi Baoquan, >> >> At 01/05/2018 12:39 PM, Baoquan He wrote: >> [...] >>> /* >>> - * Not an __init, needed by kexec/kdump code. >>> - * For safety IO-APIC and Local APIC need be cleared before this. >>> + * In legacy irq mode, full DOS compatibility with the uniprocessor PC/AT is >>> + * provided by using the APICs in conjunction with standard 8259A-equivalent >>> + * programmable interrupt controllers (PICs). It's necessary to deliver legacy >>> + * interrupts even when APIC mode is not enabled. This is required by kexec/ >>> + * kdump before enter into the 2nd kernel. >>> */ >>> void switch_to_legacy_irq_mode(void) >>> { >>> if (!nr_legacy_irqs()) >>> return; >>> - x86_io_apic_ops.disable(); >>> + ioapic_set_virtual_wire_mode(); >>> + >>> + if (boot_cpu_has(X86_FEATURE_APIC) || apic_from_smp_config()) >>> + lapic_set_legacy_irq_mode(ioapic_i8259.pin != -1); >> >> Seems these two function, ioapic/lapic_set_legacy_irq_mode should be >> exclusive. > > Thanks for looking into this, dou! > > It might be not exclusive. You can see mp_spec 3.6.2.2 Virtual Wire Mode Oops! Sorry to confuse you, here what I want to say is that the code make me think that we set through IO-APIC first, then set through Local-APIC then. But, we can be only in one mode of them. Just worry about this code seems ignore the irq remapping situation. We call switch_to_legacy_irq_mode() directly in machine_kexec(), why we also set x86_io_apic_ops: .disable = switch_to_legacy_irq_mode > subsection, there are two kinds of virtual wire mode, one is > 8259A-Equivalent pics is connected to lint0 of boot cpu LAPIC, the other > is 8259A-Equivalent pics go through IO-APIC, then is connected to lint0 > of LAPIC. Whatever it is, LAPIC need be set as through-lapic. > Yes, Absolutely right! > Above is what I got from mp_spec. But from function > native_disable_io_apic() and disconnect_bsp_APIC(), the code seems to be > telling that if io-apic is connected to 8259A-Equivalent pics, we need > mask lvt0 of LAPIC. This conflicts with mp_spec 3.6.2.2. > I think so. Thanks, dou. > Thanks > Baoquan >> >> But We do that because both the through-lapic and through-ioapic virtual >> wire mode need setup the APIC_SPIV_APIC_ENABLED which is only located in >> the lapic_set_legacy_irq_mode(). So we need call them both. >> >> IMO, this cleanup may not make it clear. we can separate these two mode >> totally or just keep it like before. >> >> Thanks, >> dou. >>> } >>> #ifdef CONFIG_X86_32 >>> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c >>> index 1151ccd72ce9..c30f0f273dbd 100644 >>> --- a/arch/x86/kernel/x86_init.c >>> +++ b/arch/x86/kernel/x86_init.c >>> @@ -148,5 +148,5 @@ void arch_restore_msi_irqs(struct pci_dev *dev) >>> struct x86_io_apic_ops x86_io_apic_ops __ro_after_init = { >>> .read = native_io_apic_read, >>> - .disable = native_disable_io_apic, >>> + .disable = switch_to_legacy_irq_mode, >>> }; >>> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c >>> index 49721b4e1975..751472ddf536 100644 >>> --- a/drivers/iommu/irq_remapping.c >>> +++ b/drivers/iommu/irq_remapping.c >>> @@ -37,7 +37,7 @@ static void irq_remapping_disable_io_apic(void) >>> * now. >>> */ >>> if (boot_cpu_has(X86_FEATURE_APIC) || apic_from_smp_config()) >>> - disconnect_bsp_APIC(0); >>> + lapic_set_legacy_irq_mode(0); >>> } >>> static void __init irq_remapping_modify_x86_ops(void) >>> >> >> > > >