Message ID | 20230410081438.1750-2-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1757028vqo; Mon, 10 Apr 2023 01:41:52 -0700 (PDT) X-Google-Smtp-Source: AKy350befmQhhrG8YE16yoUZO+DxISZiMjhXVo7CO8z2k0omM/BQkWZHM/Vs98w1xToLa8tdRyHf X-Received: by 2002:a05:6a20:6685:b0:da:2d16:db89 with SMTP id o5-20020a056a20668500b000da2d16db89mr9878383pzh.28.1681116112045; Mon, 10 Apr 2023 01:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681116112; cv=none; d=google.com; s=arc-20160816; b=iaYAqw9TtvvYRBh3ykMuO9Y34XXyzH/uSyFbqapDikzOmeevuiSLDAu94URBq90oI6 PH/jBQd6DAqI2GwLdIZBas8nubOJsX2BCxunbx92pDGhWWy3UBdLGHvC43JvA32wvOtr GvJnj3S8yb7TgZwNlH0okri2LdYdL7c0g9+/WtQMtxvxQgQ+2Ze6RnMO31fgchGZshtn QjVF0moQzeM7fybX/vsb1Q8DOQC0nWgsRyM6/JE4gmqT9GFtqBV7x7H3sFs6AgipFA8F +felNy1zZNb0376H84dW8X4a7Fbgax+KfA1lOIk5zjJVYyKyeEjah6ikKHyOFLSjfQYi AGeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=lz0rIzgfQ3UdI4kxn19lGElU0pAx4EZmyexpGqpeLQk=; b=JPqkcXupZMdJZUR1T1tnxz0aW6pceqoUb8xsunGpTUkt3xtaEzBNTAibTj3uldl9c4 8Rm7yXjJBXfNUYMne47irsvySx+dY4NUiiMmCxbB/AirqWPAFZ1gE2v9QALh946r5k5M rQrnBoq+95L0zvvhT53zZb21kQ0bMqAb0Vh+qZHWgftXCsr/oYfrl5lunv+0PmbEGPoH MPKzEPwuZiBL3HT0tge1KYLU9jMq94vBOyyNlDdychBQY4d45xMEa+nNl1vSh3OaN/e6 tK8B21OdXz4RsRd44jBxioJT2+V+FwU4QFIIByFeTxsxy4ogtv2OtWQjB9A7JqcTW7/j rM8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CINHGdc5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r20-20020a6560d4000000b0050c0305bcc3si9455111pgv.872.2023.04.10.01.41.39; Mon, 10 Apr 2023 01:41:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CINHGdc5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229725AbjDJIlI (ORCPT <rfc822;a1648639935@gmail.com> + 99 others); Mon, 10 Apr 2023 04:41:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229600AbjDJIlD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Apr 2023 04:41:03 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4AD693AB1; Mon, 10 Apr 2023 01:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681116063; x=1712652063; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CJ5cn83oehVUqkHaIiQkGH139f3gJuf37y85qUnwXYY=; b=CINHGdc5pozpD9mjU9lrfw+0Q4CL1gs6hsYyZSzlyLvql2bTYESlR0wG /svBlAF/3xakfcJRwUU/Tud/QImrQxEAHMkGehWJg3JOoslBdHw4D7bo4 msrOVEKc+qWvtkZuj2UZYLjJ6b+ucVUIRU/rp0sSbyExD2v/PqgOUdC/U bV2cbzxZKLKd/I+krss/mQIC0GXqLVCD8oCWNwAn/bebGbeCCMVsUVq6M LZ0dH0A9zvrYDIVXxFLKuE2Mqdm7NFX09Te9dLQa7RLipolrHrGtvhTkz 3WZXkV0JNRwTMOUBRCxSbySDxCkcfVJfg6nTPy+Sx4BkBi/ygesYYwi8M A==; X-IronPort-AV: E=McAfee;i="6600,9927,10675"; a="342077871" X-IronPort-AV: E=Sophos;i="5.98,333,1673942400"; d="scan'208";a="342077871" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Apr 2023 01:41:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10675"; a="799436238" X-IronPort-AV: E=Sophos;i="5.98,333,1673942400"; d="scan'208";a="799436238" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga002.fm.intel.com with ESMTP; 10 Apr 2023 01:41:01 -0700 From: Xin Li <xin3.li@intel.com> To: linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, andrew.cooper3@citrix.com, seanjc@google.com, pbonzini@redhat.com, ravi.v.shankar@intel.com, jiangshanlai@gmail.com, shan.kang@intel.com Subject: [PATCH v8 01/33] x86/traps: let common_interrupt() handle IRQ_MOVE_CLEANUP_VECTOR Date: Mon, 10 Apr 2023 01:14:06 -0700 Message-Id: <20230410081438.1750-2-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230410081438.1750-1-xin3.li@intel.com> References: <20230410081438.1750-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762778008285790143?= X-GMAIL-MSGID: =?utf-8?q?1762778008285790143?= |
Series |
x86: enable FRED for x86-64
|
|
Commit Message
Li, Xin3
April 10, 2023, 8:14 a.m. UTC
From: "H. Peter Anvin (Intel)" <hpa@zytor.com> IRQ_MOVE_CLEANUP_VECTOR is the only one of the system IRQ vectors that is *below* FIRST_SYSTEM_VECTOR. It is a slow path, so just push it into common_interrupt() just before the spurious interrupt handling. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Tested-by: Shan Kang <shan.kang@intel.com> Signed-off-by: Xin Li <xin3.li@intel.com> --- arch/x86/kernel/irq.c | 4 ++++ 1 file changed, 4 insertions(+)
Comments
On Mon, Apr 10, 2023 at 01:14:06AM -0700, Xin Li wrote: > From: "H. Peter Anvin (Intel)" <hpa@zytor.com> > > IRQ_MOVE_CLEANUP_VECTOR is the only one of the system IRQ vectors that > is *below* FIRST_SYSTEM_VECTOR. It is a slow path, so just push it > into common_interrupt() just before the spurious interrupt handling. I'm missing here the "why": I can go forward into the set and see that you're splitting the handling based on vector types and there's event classification and the lowest prio vector is not going to be hardwired to 0x20, yadda yadda... but some of that should be in the text here so that it is clear why it is being done. Thx.
> > IRQ_MOVE_CLEANUP_VECTOR is the only one of the system IRQ vectors that > > is *below* FIRST_SYSTEM_VECTOR. It is a slow path, so just push it > > into common_interrupt() just before the spurious interrupt handling. > > I'm missing here the "why": > > I can go forward into the set and see that you're splitting the handling based on > vector types and there's event classification and the lowest prio vector is not > going to be hardwired to 0x20, yadda yadda... > > but some of that should be in the text here so that it is clear why it is being done. Per Dave's ask, I am adding details about the benefits that FRED introduces, and then why we make these changes, which should make it clearer. Thanks! Xin
On Mon, Apr 10 2023 at 01:14, Xin Li wrote: > IRQ_MOVE_CLEANUP_VECTOR is the only one of the system IRQ vectors that > is *below* FIRST_SYSTEM_VECTOR. It is a slow path, so just push it > into common_interrupt() just before the spurious interrupt handling. This is a complete NOOP on not FRED enabled systems as the IDT entry is still separate. So this change makes no sense outside of the FRED universe. Can we pretty please make this consistent? Aside of that the change comes with zero justification. I can see why this is done, i.e. to spare range checking in the FRED exception entry code, but that brings up an interesting question: IRQ_MOVE_CLEANUP_VECTOR is at vector 0x20 on purpose. 0x20 is the lowest priority vector so that the following (mostly theoretical) situation gets resolved: sysvec_irq_move_cleanup() if (is_pending_in_apic_IRR(vector_to_clean_up)) apic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); I.e. when for whatever reasons the to be cleaned up vector is still pending in the local APIC IRR the function retriggers IRQ_MOVE_CLEANUP_VECTOR and returns. As the pending to be cleaned up vector has higher priority it gets handled _before_ the cleanup vector. Otherwise this ends up in a live lock. So the question is whether FRED is changing that priority scheme or not. > @@ -248,6 +248,10 @@ DEFINE_IDTENTRY_IRQ(common_interrupt) > desc = __this_cpu_read(vector_irq[vector]); > if (likely(!IS_ERR_OR_NULL(desc))) { > handle_irq(desc, regs); > +#ifdef CONFIG_SMP > + } else if (vector == IRQ_MOVE_CLEANUP_VECTOR) { > + sysvec_irq_move_cleanup(regs); This nests IDTENTRY: common_interrupt() irqentry_enter(); kvm_set_cpu_l1tf_flush_l1d(); run_irq_on_irqstack_cond(__common_interrupt, ....) __common_interrupt() sysvec_irq_move_cleanup() irqentry_enter(); <- FAIL kvm_set_cpu_l1tf_flush_l1d(); <- WHY again? run_sysvec_on_irqstack_cond(__sysvec_irq_move_cleanup); __sysvec_irq_move_cleanup(); irqentry_exit(); It does not matter whether the cleanup vector is a slow path or not. Regular interrupts are not nesting, period. Exceptions nest, but IRQ_MOVE_CLEANUP_VECTOR is not an exception and we don't make an exception for it. Stop this mindless hackery and clean it up so it is correct for all variants. Thanks, tglx
On Sat, Jun 03 2023 at 22:51, Thomas Gleixner wrote: > On Mon, Apr 10 2023 at 01:14, Xin Li wrote: >> IRQ_MOVE_CLEANUP_VECTOR is the only one of the system IRQ vectors that >> is *below* FIRST_SYSTEM_VECTOR. It is a slow path, so just push it >> into common_interrupt() just before the spurious interrupt handling. > > This is a complete NOOP on not FRED enabled systems as the IDT entry is > still separate. So this change makes no sense outside of the FRED > universe. Can we pretty please make this consistent? The right thing to make this consistent is to get rid of this vector completely. There is zero reason for this to be an IPI. This can be delegated to a worker or whatever delayed mechanism. Thanks, tglx
On 6/5/23 10:07, Thomas Gleixner wrote: > On Sat, Jun 03 2023 at 22:51, Thomas Gleixner wrote: >> On Mon, Apr 10 2023 at 01:14, Xin Li wrote: >>> IRQ_MOVE_CLEANUP_VECTOR is the only one of the system IRQ vectors that >>> is *below* FIRST_SYSTEM_VECTOR. It is a slow path, so just push it >>> into common_interrupt() just before the spurious interrupt handling. >> >> This is a complete NOOP on not FRED enabled systems as the IDT entry is >> still separate. So this change makes no sense outside of the FRED >> universe. Can we pretty please make this consistent? > > The right thing to make this consistent is to get rid of this vector > completely. > > There is zero reason for this to be an IPI. This can be delegated to a > worker or whatever delayed mechanism. > As we discussed offline, I agree that this is a better solution (and should be a separate changeset before the FRED one.) -hpa
On Mon, Jun 05 2023 at 10:09, H. Peter Anvin wrote: > On 6/5/23 10:07, Thomas Gleixner wrote: >> There is zero reason for this to be an IPI. This can be delegated to a >> worker or whatever delayed mechanism. >> > As we discussed offline, I agree that this is a better solution (and > should be a separate changeset before the FRED one.) The untested below should do the trick. Wants to be split in several patches, but you get the idea. Thanks, tglx --- Subject: x86/vector: Get rid of IRQ_MOVE_CLEANUP_VECTOR From: Thomas Gleixner <tglx@linutronix.de> No point to waste a vector for cleaning up the leftovers of a moved interrupt. Aside of that this must be the lowest priority of all vectors which makes FRED systems utilizing vectors 0x10-0x1f more complicated than necessary. Schedule a timer instead. Not-Yet-Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- arch/x86/include/asm/hw_irq.h | 4 - arch/x86/include/asm/idtentry.h | 1 arch/x86/include/asm/irq_vectors.h | 7 --- arch/x86/kernel/apic/vector.c | 83 ++++++++++++++++++++++++++---------- arch/x86/kernel/idt.c | 1 arch/x86/platform/uv/uv_irq.c | 2 drivers/iommu/amd/iommu.c | 2 drivers/iommu/hyperv-iommu.c | 4 - drivers/iommu/intel/irq_remapping.c | 2 9 files changed, 68 insertions(+), 38 deletions(-) --- a/arch/x86/include/asm/hw_irq.h +++ b/arch/x86/include/asm/hw_irq.h @@ -97,10 +97,10 @@ extern struct irq_cfg *irqd_cfg(struct i extern void lock_vector_lock(void); extern void unlock_vector_lock(void); #ifdef CONFIG_SMP -extern void send_cleanup_vector(struct irq_cfg *); +extern void vector_schedule_cleanup(struct irq_cfg *); extern void irq_complete_move(struct irq_cfg *cfg); #else -static inline void send_cleanup_vector(struct irq_cfg *c) { } +static inline void vector_schedule_cleanup(struct irq_cfg *c) { } static inline void irq_complete_move(struct irq_cfg *c) { } #endif --- a/arch/x86/include/asm/idtentry.h +++ b/arch/x86/include/asm/idtentry.h @@ -648,7 +648,6 @@ DECLARE_IDTENTRY_SYSVEC(X86_PLATFORM_IPI #ifdef CONFIG_SMP DECLARE_IDTENTRY(RESCHEDULE_VECTOR, sysvec_reschedule_ipi); -DECLARE_IDTENTRY_SYSVEC(IRQ_MOVE_CLEANUP_VECTOR, sysvec_irq_move_cleanup); DECLARE_IDTENTRY_SYSVEC(REBOOT_VECTOR, sysvec_reboot); DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, sysvec_call_function_single); DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_VECTOR, sysvec_call_function); --- a/arch/x86/include/asm/irq_vectors.h +++ b/arch/x86/include/asm/irq_vectors.h @@ -35,13 +35,6 @@ */ #define FIRST_EXTERNAL_VECTOR 0x20 -/* - * Reserve the lowest usable vector (and hence lowest priority) 0x20 for - * triggering cleanup after irq migration. 0x21-0x2f will still be used - * for device interrupts. - */ -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_EXTERNAL_VECTOR - #define IA32_SYSCALL_VECTOR 0x80 /* --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -44,7 +44,18 @@ static cpumask_var_t vector_searchmask; static struct irq_chip lapic_controller; static struct irq_matrix *vector_matrix; #ifdef CONFIG_SMP -static DEFINE_PER_CPU(struct hlist_head, cleanup_list); + +static void vector_cleanup_callback(struct timer_list *tmr); + +struct vector_cleanup { + struct hlist_head head; + struct timer_list timer; +}; + +static DEFINE_PER_CPU(struct vector_cleanup, vector_cleanup) = { + .head = HLIST_HEAD_INIT, + .timer = __TIMER_INITIALIZER(vector_cleanup_callback, TIMER_PINNED), +}; #endif void lock_vector_lock(void) @@ -843,8 +854,12 @@ void lapic_online(void) void lapic_offline(void) { + struct vector_cleanup *cl = this_cpu_ptr(&vector_cleanup); + lock_vector_lock(); irq_matrix_offline(vector_matrix); + WARN_ON_ONCE(try_to_del_timer_sync(&cl->timer) < 0); + WARN_ON_ONCE(!hlist_empty(&cl->head)); unlock_vector_lock(); } @@ -934,62 +949,86 @@ static void free_moved_vector(struct api apicd->move_in_progress = 0; } -DEFINE_IDTENTRY_SYSVEC(sysvec_irq_move_cleanup) +static void vector_cleanup_callback(struct timer_list *tmr) { - struct hlist_head *clhead = this_cpu_ptr(&cleanup_list); + struct vector_cleanup *cl = container_of(tmr, typeof(*cl), timer); struct apic_chip_data *apicd; struct hlist_node *tmp; + bool rearm = false; - ack_APIC_irq(); /* Prevent vectors vanishing under us */ - raw_spin_lock(&vector_lock); + raw_spin_lock_irq(&vector_lock); - hlist_for_each_entry_safe(apicd, tmp, clhead, clist) { + hlist_for_each_entry_safe(apicd, tmp, &cl->head, clist) { unsigned int irr, vector = apicd->prev_vector; /* * Paranoia: Check if the vector that needs to be cleaned - * up is registered at the APICs IRR. If so, then this is - * not the best time to clean it up. Clean it up in the - * next attempt by sending another IRQ_MOVE_CLEANUP_VECTOR - * to this CPU. IRQ_MOVE_CLEANUP_VECTOR is the lowest - * priority external vector, so on return from this - * interrupt the device interrupt will happen first. + * up is registered at the APICs IRR. That's clearly a + * hardware issue if the vector arrived on the old target + * _after_ interrupts were disabled above. Keep @apicd + * on the list and schedule the timer again to give the CPU + * a chance to handle the pending interrupt. */ irr = apic_read(APIC_IRR + (vector / 32 * 0x10)); if (irr & (1U << (vector % 32))) { - apic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); + pr_warn_once("Moved interrupt pending in old target APIC %u\n", apicd->irq); + rearm = true; continue; } free_moved_vector(apicd); } - raw_spin_unlock(&vector_lock); + /* + * Must happen under vector_lock to make the timer_pending() check + * in __vector_schedule_cleanup() race free against the rearm here. + */ + if (rearm) + mod_timer(tmr, jiffies + 1); + + raw_spin_unlock_irq(&vector_lock); } -static void __send_cleanup_vector(struct apic_chip_data *apicd) +static void __vector_schedule_cleanup(struct apic_chip_data *apicd) { - unsigned int cpu; + unsigned int cpu = apicd->prev_cpu; raw_spin_lock(&vector_lock); apicd->move_in_progress = 0; - cpu = apicd->prev_cpu; if (cpu_online(cpu)) { - hlist_add_head(&apicd->clist, per_cpu_ptr(&cleanup_list, cpu)); - apic->send_IPI(cpu, IRQ_MOVE_CLEANUP_VECTOR); + struct vector_cleanup *cl = per_cpu_ptr(&vector_cleanup, cpu); + + /* + * The lockless timer_pending() check is safe here. If it + * returns true, then the callback will observe this new + * apic data in the hlist as everything is serialized by + * vector lock. + * + * If it returns false then the timer is either not armed + * or the other CPU executes the callback, which again + * would be blocked on vector lock. Rearming it in the + * latter case makes it fire for nothing. + * + * This is also safe against the callback rearming the timer + * because that's serialized via vector lock too. + */ + if (!timer_pending(&cl->timer)) { + cl->timer.expires = jiffies + 1; + add_timer_on(&cl->timer, cpu); + } } else { apicd->prev_vector = 0; } raw_spin_unlock(&vector_lock); } -void send_cleanup_vector(struct irq_cfg *cfg) +void vector_schedule_cleanup(struct irq_cfg *cfg) { struct apic_chip_data *apicd; apicd = container_of(cfg, struct apic_chip_data, hw_irq_cfg); if (apicd->move_in_progress) - __send_cleanup_vector(apicd); + __vector_schedule_cleanup(apicd); } void irq_complete_move(struct irq_cfg *cfg) @@ -1007,7 +1046,7 @@ void irq_complete_move(struct irq_cfg *c * on the same CPU. */ if (apicd->cpu == smp_processor_id()) - __send_cleanup_vector(apicd); + __vector_schedule_cleanup(apicd); } /* --- a/arch/x86/kernel/idt.c +++ b/arch/x86/kernel/idt.c @@ -131,7 +131,6 @@ static const __initconst struct idt_data INTG(RESCHEDULE_VECTOR, asm_sysvec_reschedule_ipi), INTG(CALL_FUNCTION_VECTOR, asm_sysvec_call_function), INTG(CALL_FUNCTION_SINGLE_VECTOR, asm_sysvec_call_function_single), - INTG(IRQ_MOVE_CLEANUP_VECTOR, asm_sysvec_irq_move_cleanup), INTG(REBOOT_VECTOR, asm_sysvec_reboot), #endif --- a/arch/x86/platform/uv/uv_irq.c +++ b/arch/x86/platform/uv/uv_irq.c @@ -58,7 +58,7 @@ uv_set_irq_affinity(struct irq_data *dat ret = parent->chip->irq_set_affinity(parent, mask, force); if (ret >= 0) { uv_program_mmr(cfg, data->chip_data); - send_cleanup_vector(cfg); + vector_schedule_cleanup(cfg); } return ret; --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -3639,7 +3639,7 @@ static int amd_ir_set_affinity(struct ir * at the new destination. So, time to cleanup the previous * vector allocation. */ - send_cleanup_vector(cfg); + vector_schedule_cleanup(cfg); return IRQ_SET_MASK_OK_DONE; } --- a/drivers/iommu/hyperv-iommu.c +++ b/drivers/iommu/hyperv-iommu.c @@ -51,7 +51,7 @@ static int hyperv_ir_set_affinity(struct if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE) return ret; - send_cleanup_vector(cfg); + vector_schedule_cleanup(cfg); return 0; } @@ -257,7 +257,7 @@ static int hyperv_root_ir_set_affinity(s if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE) return ret; - send_cleanup_vector(cfg); + vector_schedule_cleanup(cfg); return 0; } --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -1180,7 +1180,7 @@ intel_ir_set_affinity(struct irq_data *d * at the new destination. So, time to cleanup the previous * vector allocation. */ - send_cleanup_vector(cfg); + vector_schedule_cleanup(cfg); return IRQ_SET_MASK_OK_DONE; }
> The untested below should do the trick. Wants to be split in several patches, but > you get the idea. I will continue the work from what you posted. Thanks a lot! Xin > --- > Subject: x86/vector: Get rid of IRQ_MOVE_CLEANUP_VECTOR > From: Thomas Gleixner <tglx@linutronix.de> > > No point to waste a vector for cleaning up the leftovers of a moved interrupt. > Aside of that this must be the lowest priority of all vectors which makes FRED > systems utilizing vectors 0x10-0x1f more complicated than necessary. > > Schedule a timer instead. > > Not-Yet-Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > --- > arch/x86/include/asm/hw_irq.h | 4 - > arch/x86/include/asm/idtentry.h | 1 > arch/x86/include/asm/irq_vectors.h | 7 --- > arch/x86/kernel/apic/vector.c | 83 ++++++++++++++++++++++++++---------- > arch/x86/kernel/idt.c | 1 > arch/x86/platform/uv/uv_irq.c | 2 > drivers/iommu/amd/iommu.c | 2 > drivers/iommu/hyperv-iommu.c | 4 - > drivers/iommu/intel/irq_remapping.c | 2 > 9 files changed, 68 insertions(+), 38 deletions(-) > > --- a/arch/x86/include/asm/hw_irq.h > +++ b/arch/x86/include/asm/hw_irq.h > @@ -97,10 +97,10 @@ extern struct irq_cfg *irqd_cfg(struct i extern void > lock_vector_lock(void); extern void unlock_vector_lock(void); #ifdef > CONFIG_SMP -extern void send_cleanup_vector(struct irq_cfg *); > +extern void vector_schedule_cleanup(struct irq_cfg *); > extern void irq_complete_move(struct irq_cfg *cfg); #else -static inline void > send_cleanup_vector(struct irq_cfg *c) { } > +static inline void vector_schedule_cleanup(struct irq_cfg *c) { } > static inline void irq_complete_move(struct irq_cfg *c) { } #endif > > --- a/arch/x86/include/asm/idtentry.h > +++ b/arch/x86/include/asm/idtentry.h > @@ -648,7 +648,6 @@ DECLARE_IDTENTRY_SYSVEC(X86_PLATFORM_IPI > > #ifdef CONFIG_SMP > DECLARE_IDTENTRY(RESCHEDULE_VECTOR, > sysvec_reschedule_ipi); > -DECLARE_IDTENTRY_SYSVEC(IRQ_MOVE_CLEANUP_VECTOR, > sysvec_irq_move_cleanup); > DECLARE_IDTENTRY_SYSVEC(REBOOT_VECTOR, > sysvec_reboot); > DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, > sysvec_call_function_single); > DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_VECTOR, > sysvec_call_function); > --- a/arch/x86/include/asm/irq_vectors.h > +++ b/arch/x86/include/asm/irq_vectors.h > @@ -35,13 +35,6 @@ > */ > #define FIRST_EXTERNAL_VECTOR 0x20 > > -/* > - * Reserve the lowest usable vector (and hence lowest priority) 0x20 for > - * triggering cleanup after irq migration. 0x21-0x2f will still be used > - * for device interrupts. > - */ > -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_EXTERNAL_VECTOR > - > #define IA32_SYSCALL_VECTOR 0x80 > > /* > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@ -44,7 +44,18 @@ static cpumask_var_t vector_searchmask; static struct > irq_chip lapic_controller; static struct irq_matrix *vector_matrix; #ifdef > CONFIG_SMP -static DEFINE_PER_CPU(struct hlist_head, cleanup_list); > + > +static void vector_cleanup_callback(struct timer_list *tmr); > + > +struct vector_cleanup { > + struct hlist_head head; > + struct timer_list timer; > +}; > + > +static DEFINE_PER_CPU(struct vector_cleanup, vector_cleanup) = { > + .head = HLIST_HEAD_INIT, > + .timer = __TIMER_INITIALIZER(vector_cleanup_callback, > TIMER_PINNED), > +}; > #endif > > void lock_vector_lock(void) > @@ -843,8 +854,12 @@ void lapic_online(void) > > void lapic_offline(void) > { > + struct vector_cleanup *cl = this_cpu_ptr(&vector_cleanup); > + > lock_vector_lock(); > irq_matrix_offline(vector_matrix); > + WARN_ON_ONCE(try_to_del_timer_sync(&cl->timer) < 0); > + WARN_ON_ONCE(!hlist_empty(&cl->head)); > unlock_vector_lock(); > } > > @@ -934,62 +949,86 @@ static void free_moved_vector(struct api > apicd->move_in_progress = 0; > } > > -DEFINE_IDTENTRY_SYSVEC(sysvec_irq_move_cleanup) > +static void vector_cleanup_callback(struct timer_list *tmr) > { > - struct hlist_head *clhead = this_cpu_ptr(&cleanup_list); > + struct vector_cleanup *cl = container_of(tmr, typeof(*cl), timer); > struct apic_chip_data *apicd; > struct hlist_node *tmp; > + bool rearm = false; > > - ack_APIC_irq(); > /* Prevent vectors vanishing under us */ > - raw_spin_lock(&vector_lock); > + raw_spin_lock_irq(&vector_lock); > > - hlist_for_each_entry_safe(apicd, tmp, clhead, clist) { > + hlist_for_each_entry_safe(apicd, tmp, &cl->head, clist) { > unsigned int irr, vector = apicd->prev_vector; > > /* > * Paranoia: Check if the vector that needs to be cleaned > - * up is registered at the APICs IRR. If so, then this is > - * not the best time to clean it up. Clean it up in the > - * next attempt by sending another > IRQ_MOVE_CLEANUP_VECTOR > - * to this CPU. IRQ_MOVE_CLEANUP_VECTOR is the lowest > - * priority external vector, so on return from this > - * interrupt the device interrupt will happen first. > + * up is registered at the APICs IRR. That's clearly a > + * hardware issue if the vector arrived on the old target > + * _after_ interrupts were disabled above. Keep @apicd > + * on the list and schedule the timer again to give the CPU > + * a chance to handle the pending interrupt. > */ > irr = apic_read(APIC_IRR + (vector / 32 * 0x10)); > if (irr & (1U << (vector % 32))) { > - apic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); > + pr_warn_once("Moved interrupt pending in old target > APIC %u\n", apicd->irq); > + rearm = true; > continue; > } > free_moved_vector(apicd); > } > > - raw_spin_unlock(&vector_lock); > + /* > + * Must happen under vector_lock to make the timer_pending() check > + * in __vector_schedule_cleanup() race free against the rearm here. > + */ > + if (rearm) > + mod_timer(tmr, jiffies + 1); > + > + raw_spin_unlock_irq(&vector_lock); > } > > -static void __send_cleanup_vector(struct apic_chip_data *apicd) > +static void __vector_schedule_cleanup(struct apic_chip_data *apicd) > { > - unsigned int cpu; > + unsigned int cpu = apicd->prev_cpu; > > raw_spin_lock(&vector_lock); > apicd->move_in_progress = 0; > - cpu = apicd->prev_cpu; > if (cpu_online(cpu)) { > - hlist_add_head(&apicd->clist, per_cpu_ptr(&cleanup_list, cpu)); > - apic->send_IPI(cpu, IRQ_MOVE_CLEANUP_VECTOR); > + struct vector_cleanup *cl = per_cpu_ptr(&vector_cleanup, cpu); > + > + /* > + * The lockless timer_pending() check is safe here. If it > + * returns true, then the callback will observe this new > + * apic data in the hlist as everything is serialized by > + * vector lock. > + * > + * If it returns false then the timer is either not armed > + * or the other CPU executes the callback, which again > + * would be blocked on vector lock. Rearming it in the > + * latter case makes it fire for nothing. > + * > + * This is also safe against the callback rearming the timer > + * because that's serialized via vector lock too. > + */ > + if (!timer_pending(&cl->timer)) { > + cl->timer.expires = jiffies + 1; > + add_timer_on(&cl->timer, cpu); > + } > } else { > apicd->prev_vector = 0; > } > raw_spin_unlock(&vector_lock); > } > > -void send_cleanup_vector(struct irq_cfg *cfg) > +void vector_schedule_cleanup(struct irq_cfg *cfg) > { > struct apic_chip_data *apicd; > > apicd = container_of(cfg, struct apic_chip_data, hw_irq_cfg); > if (apicd->move_in_progress) > - __send_cleanup_vector(apicd); > + __vector_schedule_cleanup(apicd); > } > > void irq_complete_move(struct irq_cfg *cfg) @@ -1007,7 +1046,7 @@ void > irq_complete_move(struct irq_cfg *c > * on the same CPU. > */ > if (apicd->cpu == smp_processor_id()) > - __send_cleanup_vector(apicd); > + __vector_schedule_cleanup(apicd); > } > > /* > --- a/arch/x86/kernel/idt.c > +++ b/arch/x86/kernel/idt.c > @@ -131,7 +131,6 @@ static const __initconst struct idt_data > INTG(RESCHEDULE_VECTOR, > asm_sysvec_reschedule_ipi), > INTG(CALL_FUNCTION_VECTOR, > asm_sysvec_call_function), > INTG(CALL_FUNCTION_SINGLE_VECTOR, > asm_sysvec_call_function_single), > - INTG(IRQ_MOVE_CLEANUP_VECTOR, > asm_sysvec_irq_move_cleanup), > INTG(REBOOT_VECTOR, asm_sysvec_reboot), > #endif > > --- a/arch/x86/platform/uv/uv_irq.c > +++ b/arch/x86/platform/uv/uv_irq.c > @@ -58,7 +58,7 @@ uv_set_irq_affinity(struct irq_data *dat > ret = parent->chip->irq_set_affinity(parent, mask, force); > if (ret >= 0) { > uv_program_mmr(cfg, data->chip_data); > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > } > > return ret; > --- a/drivers/iommu/amd/iommu.c > +++ b/drivers/iommu/amd/iommu.c > @@ -3639,7 +3639,7 @@ static int amd_ir_set_affinity(struct ir > * at the new destination. So, time to cleanup the previous > * vector allocation. > */ > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return IRQ_SET_MASK_OK_DONE; > } > --- a/drivers/iommu/hyperv-iommu.c > +++ b/drivers/iommu/hyperv-iommu.c > @@ -51,7 +51,7 @@ static int hyperv_ir_set_affinity(struct > if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE) > return ret; > > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return 0; > } > @@ -257,7 +257,7 @@ static int hyperv_root_ir_set_affinity(s > if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE) > return ret; > > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return 0; > } > --- a/drivers/iommu/intel/irq_remapping.c > +++ b/drivers/iommu/intel/irq_remapping.c > @@ -1180,7 +1180,7 @@ intel_ir_set_affinity(struct irq_data *d > * at the new destination. So, time to cleanup the previous > * vector allocation. > */ > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return IRQ_SET_MASK_OK_DONE; > }
> The untested below should do the trick. Wants to be split in several > patches, but you get the idea. Hi Thomas, How do you want to split the patch? To me it's better to keep the changes in one patch, thus the differences are more obvious. We need a second patch to do vector cleanup in lapic_offline() in case the vector cleanup timer has not expired. But I don't see a good way to split your draft patch (I only have a minor fix on it). Thanks! Xin > > Thanks, > > tglx > --- > Subject: x86/vector: Get rid of IRQ_MOVE_CLEANUP_VECTOR > From: Thomas Gleixner <tglx@linutronix.de> > > No point to waste a vector for cleaning up the leftovers of a moved > interrupt. Aside of that this must be the lowest priority of all vectors > which makes FRED systems utilizing vectors 0x10-0x1f more complicated > than necessary. > > Schedule a timer instead. > > Not-Yet-Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > --- > arch/x86/include/asm/hw_irq.h | 4 - > arch/x86/include/asm/idtentry.h | 1 > arch/x86/include/asm/irq_vectors.h | 7 --- > arch/x86/kernel/apic/vector.c | 83 ++++++++++++++++++++++++++---------- > arch/x86/kernel/idt.c | 1 > arch/x86/platform/uv/uv_irq.c | 2 > drivers/iommu/amd/iommu.c | 2 > drivers/iommu/hyperv-iommu.c | 4 - > drivers/iommu/intel/irq_remapping.c | 2 > 9 files changed, 68 insertions(+), 38 deletions(-) > > --- a/arch/x86/include/asm/hw_irq.h > +++ b/arch/x86/include/asm/hw_irq.h > @@ -97,10 +97,10 @@ extern struct irq_cfg *irqd_cfg(struct i > extern void lock_vector_lock(void); > extern void unlock_vector_lock(void); > #ifdef CONFIG_SMP > -extern void send_cleanup_vector(struct irq_cfg *); > +extern void vector_schedule_cleanup(struct irq_cfg *); > extern void irq_complete_move(struct irq_cfg *cfg); > #else > -static inline void send_cleanup_vector(struct irq_cfg *c) { } > +static inline void vector_schedule_cleanup(struct irq_cfg *c) { } > static inline void irq_complete_move(struct irq_cfg *c) { } > #endif > > --- a/arch/x86/include/asm/idtentry.h > +++ b/arch/x86/include/asm/idtentry.h > @@ -648,7 +648,6 @@ DECLARE_IDTENTRY_SYSVEC(X86_PLATFORM_IPI > > #ifdef CONFIG_SMP > DECLARE_IDTENTRY(RESCHEDULE_VECTOR, > sysvec_reschedule_ipi); > -DECLARE_IDTENTRY_SYSVEC(IRQ_MOVE_CLEANUP_VECTOR, > sysvec_irq_move_cleanup); > DECLARE_IDTENTRY_SYSVEC(REBOOT_VECTOR, sysvec_reboot); > DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, > sysvec_call_function_single); > DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_VECTOR, > sysvec_call_function); > --- a/arch/x86/include/asm/irq_vectors.h > +++ b/arch/x86/include/asm/irq_vectors.h > @@ -35,13 +35,6 @@ > */ > #define FIRST_EXTERNAL_VECTOR 0x20 > > -/* > - * Reserve the lowest usable vector (and hence lowest priority) 0x20 for > - * triggering cleanup after irq migration. 0x21-0x2f will still be used > - * for device interrupts. > - */ > -#define IRQ_MOVE_CLEANUP_VECTOR FIRST_EXTERNAL_VECTOR > - > #define IA32_SYSCALL_VECTOR 0x80 > > /* > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@ -44,7 +44,18 @@ static cpumask_var_t vector_searchmask; > static struct irq_chip lapic_controller; > static struct irq_matrix *vector_matrix; > #ifdef CONFIG_SMP > -static DEFINE_PER_CPU(struct hlist_head, cleanup_list); > + > +static void vector_cleanup_callback(struct timer_list *tmr); > + > +struct vector_cleanup { > + struct hlist_head head; > + struct timer_list timer; > +}; > + > +static DEFINE_PER_CPU(struct vector_cleanup, vector_cleanup) = { > + .head = HLIST_HEAD_INIT, > + .timer = __TIMER_INITIALIZER(vector_cleanup_callback, TIMER_PINNED), > +}; > #endif > > void lock_vector_lock(void) > @@ -843,8 +854,12 @@ void lapic_online(void) > > void lapic_offline(void) > { > + struct vector_cleanup *cl = this_cpu_ptr(&vector_cleanup); > + > lock_vector_lock(); > irq_matrix_offline(vector_matrix); > + WARN_ON_ONCE(try_to_del_timer_sync(&cl->timer) < 0); > + WARN_ON_ONCE(!hlist_empty(&cl->head)); > unlock_vector_lock(); > } > > @@ -934,62 +949,86 @@ static void free_moved_vector(struct api > apicd->move_in_progress = 0; > } > > -DEFINE_IDTENTRY_SYSVEC(sysvec_irq_move_cleanup) > +static void vector_cleanup_callback(struct timer_list *tmr) > { > - struct hlist_head *clhead = this_cpu_ptr(&cleanup_list); > + struct vector_cleanup *cl = container_of(tmr, typeof(*cl), timer); > struct apic_chip_data *apicd; > struct hlist_node *tmp; > + bool rearm = false; > > - ack_APIC_irq(); > /* Prevent vectors vanishing under us */ > - raw_spin_lock(&vector_lock); > + raw_spin_lock_irq(&vector_lock); > > - hlist_for_each_entry_safe(apicd, tmp, clhead, clist) { > + hlist_for_each_entry_safe(apicd, tmp, &cl->head, clist) { > unsigned int irr, vector = apicd->prev_vector; > > /* > * Paranoia: Check if the vector that needs to be cleaned > - * up is registered at the APICs IRR. If so, then this is > - * not the best time to clean it up. Clean it up in the > - * next attempt by sending another IRQ_MOVE_CLEANUP_VECTOR > - * to this CPU. IRQ_MOVE_CLEANUP_VECTOR is the lowest > - * priority external vector, so on return from this > - * interrupt the device interrupt will happen first. > + * up is registered at the APICs IRR. That's clearly a > + * hardware issue if the vector arrived on the old target > + * _after_ interrupts were disabled above. Keep @apicd > + * on the list and schedule the timer again to give the CPU > + * a chance to handle the pending interrupt. > */ > irr = apic_read(APIC_IRR + (vector / 32 * 0x10)); > if (irr & (1U << (vector % 32))) { > - apic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR); > + pr_warn_once("Moved interrupt pending in old target APIC > %u\n", apicd->irq); > + rearm = true; > continue; > } > free_moved_vector(apicd); > } > > - raw_spin_unlock(&vector_lock); > + /* > + * Must happen under vector_lock to make the timer_pending() check > + * in __vector_schedule_cleanup() race free against the rearm here. > + */ > + if (rearm) > + mod_timer(tmr, jiffies + 1); > + > + raw_spin_unlock_irq(&vector_lock); > } > > -static void __send_cleanup_vector(struct apic_chip_data *apicd) > +static void __vector_schedule_cleanup(struct apic_chip_data *apicd) > { > - unsigned int cpu; > + unsigned int cpu = apicd->prev_cpu; > > raw_spin_lock(&vector_lock); > apicd->move_in_progress = 0; > - cpu = apicd->prev_cpu; > if (cpu_online(cpu)) { > - hlist_add_head(&apicd->clist, per_cpu_ptr(&cleanup_list, cpu)); > - apic->send_IPI(cpu, IRQ_MOVE_CLEANUP_VECTOR); > + struct vector_cleanup *cl = per_cpu_ptr(&vector_cleanup, cpu); > + > + /* > + * The lockless timer_pending() check is safe here. If it > + * returns true, then the callback will observe this new > + * apic data in the hlist as everything is serialized by > + * vector lock. > + * > + * If it returns false then the timer is either not armed > + * or the other CPU executes the callback, which again > + * would be blocked on vector lock. Rearming it in the > + * latter case makes it fire for nothing. > + * > + * This is also safe against the callback rearming the timer > + * because that's serialized via vector lock too. > + */ > + if (!timer_pending(&cl->timer)) { > + cl->timer.expires = jiffies + 1; > + add_timer_on(&cl->timer, cpu); > + } > } else { > apicd->prev_vector = 0; > } > raw_spin_unlock(&vector_lock); > } > > -void send_cleanup_vector(struct irq_cfg *cfg) > +void vector_schedule_cleanup(struct irq_cfg *cfg) > { > struct apic_chip_data *apicd; > > apicd = container_of(cfg, struct apic_chip_data, hw_irq_cfg); > if (apicd->move_in_progress) > - __send_cleanup_vector(apicd); > + __vector_schedule_cleanup(apicd); > } > > void irq_complete_move(struct irq_cfg *cfg) > @@ -1007,7 +1046,7 @@ void irq_complete_move(struct irq_cfg *c > * on the same CPU. > */ > if (apicd->cpu == smp_processor_id()) > - __send_cleanup_vector(apicd); > + __vector_schedule_cleanup(apicd); > } > > /* > --- a/arch/x86/kernel/idt.c > +++ b/arch/x86/kernel/idt.c > @@ -131,7 +131,6 @@ static const __initconst struct idt_data > INTG(RESCHEDULE_VECTOR, > asm_sysvec_reschedule_ipi), > INTG(CALL_FUNCTION_VECTOR, asm_sysvec_call_function), > INTG(CALL_FUNCTION_SINGLE_VECTOR, asm_sysvec_call_function_single), > - INTG(IRQ_MOVE_CLEANUP_VECTOR, > asm_sysvec_irq_move_cleanup), > INTG(REBOOT_VECTOR, asm_sysvec_reboot), > #endif > > --- a/arch/x86/platform/uv/uv_irq.c > +++ b/arch/x86/platform/uv/uv_irq.c > @@ -58,7 +58,7 @@ uv_set_irq_affinity(struct irq_data *dat > ret = parent->chip->irq_set_affinity(parent, mask, force); > if (ret >= 0) { > uv_program_mmr(cfg, data->chip_data); > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > } > > return ret; > --- a/drivers/iommu/amd/iommu.c > +++ b/drivers/iommu/amd/iommu.c > @@ -3639,7 +3639,7 @@ static int amd_ir_set_affinity(struct ir > * at the new destination. So, time to cleanup the previous > * vector allocation. > */ > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return IRQ_SET_MASK_OK_DONE; > } > --- a/drivers/iommu/hyperv-iommu.c > +++ b/drivers/iommu/hyperv-iommu.c > @@ -51,7 +51,7 @@ static int hyperv_ir_set_affinity(struct > if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE) > return ret; > > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return 0; > } > @@ -257,7 +257,7 @@ static int hyperv_root_ir_set_affinity(s > if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE) > return ret; > > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return 0; > } > --- a/drivers/iommu/intel/irq_remapping.c > +++ b/drivers/iommu/intel/irq_remapping.c > @@ -1180,7 +1180,7 @@ intel_ir_set_affinity(struct irq_data *d > * at the new destination. So, time to cleanup the previous > * vector allocation. > */ > - send_cleanup_vector(cfg); > + vector_schedule_cleanup(cfg); > > return IRQ_SET_MASK_OK_DONE; > }
On Mon, Jun 19 2023 at 08:00, Li, Xin3 wrote: > To me it's better to keep the changes in one patch, thus the differences > are more obvious. The rename to vector_schedule_cleanup() can be obviously done first. > We need a second patch to do vector cleanup in lapic_offline() in case the > vector cleanup timer has not expired. Right. I was lazy and just put a WARN_ON() there under the assumption that you will figure it out. But a second patch? We don't switch things over into a broken state first and then fix it up afterwards. Thanks, tglx
> > To me it's better to keep the changes in one patch, thus the > > differences are more obvious. > > The rename to vector_schedule_cleanup() can be obviously done first. Okay, it's a bit wired to me to rename before any actual code logic change. > > > We need a second patch to do vector cleanup in lapic_offline() in case > > the vector cleanup timer has not expired. > > Right. I was lazy and just put a WARN_ON() there under the assumption that you > will figure it out. I see that, as your changes to lapic_offline() are completely new. > But a second patch? > > We don't switch things over into a broken state first and then fix it up afterwards. Make sense!
On June 19, 2023 11:47:08 AM PDT, "Li, Xin3" <xin3.li@intel.com> wrote: >> > To me it's better to keep the changes in one patch, thus the >> > differences are more obvious. >> >> The rename to vector_schedule_cleanup() can be obviously done first. > >Okay, it's a bit wired to me to rename before any actual code logic change. > Weird or not, that's the established practice. However, if you think about it, it makes sense: that way your code logic patch doesn't contain a bunch of names which will almost immediately be outdated. That is *really* confusing when you are going back through the git history, for example. >> >> > We need a second patch to do vector cleanup in lapic_offline() in case >> > the vector cleanup timer has not expired. >> >> Right. I was lazy and just put a WARN_ON() there under the assumption that you >> will figure it out. > >I see that, as your changes to lapic_offline() are completely new. > >> But a second patch? >> >> We don't switch things over into a broken state first and then fix it up afterwards. > >Make sense! >
> >Okay, it's a bit wired to me to rename before any actual code logic change. > > > > Weird or not, that's the established practice. > > However, if you think about it, it makes sense: that way your code logic patch > doesn't contain a bunch of names which will almost immediately be outdated. That > is *really* confusing when you are going back through the git history, for example. Thanks for the clarification! Xin
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 766ffe3ba313..7e125fff45ab 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -248,6 +248,10 @@ DEFINE_IDTENTRY_IRQ(common_interrupt) desc = __this_cpu_read(vector_irq[vector]); if (likely(!IS_ERR_OR_NULL(desc))) { handle_irq(desc, regs); +#ifdef CONFIG_SMP + } else if (vector == IRQ_MOVE_CLEANUP_VECTOR) { + sysvec_irq_move_cleanup(regs); +#endif } else { ack_APIC_irq();