All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: "Troy Mitchell" <troy.mitchell@linux.dev>,
	"Anup Patel" <anup@brainfault.org>,
	"Radu Rendec" <radu@rendec.net>, "Paul Walmsley" <pjw@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Björn Töpel" <bjorn@rivosinc.com>
Cc: Anup Patel <apatel@ventanamicro.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Troy Mitchell <troy.mitchell@linux.dev>
Subject: Re: [PATCH v2 2/2] irqchip/riscv-aplic: Apply pending affinity changes for level MSI sources
Date: Wed, 11 Nov 2026 01:09:20 +0100	[thread overview]
Message-ID: <87fqx8tej3.ffs@fw13> (raw)
In-Reply-To: <20261110-aplic-affinity-fix-v2-2-6c143b8b4e8c@linux.dev>

On Tue, Nov 10 2026 at 12:06, Troy Mitchell wrote:

> IMSIC rejects an affinity change with -EBUSY while a previous vector
> move is still in flight, and the IRQ core then records the new mask as
> pending. The change is applied by irq_move_irq() in the IMSIC irq_ack
> callback, but level-triggered APLIC MSI interrupts are handled by
> handle_fasteoi_irq(), which never calls irq_ack.
>
> The pending change is therefore never applied. While it is pending,
> later affinity changes only update the pending mask, so the interrupt
> stays on its old CPU.
>
> Use handle_fasteoi_ack_irq() for level-triggered sources. It acks the
> interrupt before invoking the handler, so a pending affinity change is
> applied on the next interrupt, and the EOI retrigger then targets the
> new CPU.

Smart!

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@kernel.org>
To: "Troy Mitchell" <troy.mitchell@linux.dev>,
	"Anup Patel" <anup@brainfault.org>,
	"Radu Rendec" <radu@rendec.net>, "Paul Walmsley" <pjw@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Björn Töpel" <bjorn@rivosinc.com>
Cc: Anup Patel <apatel@ventanamicro.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Troy Mitchell <troy.mitchell@linux.dev>
Subject: Re: [PATCH v2 2/2] irqchip/riscv-aplic: Apply pending affinity changes for level MSI sources
Date: Wed, 11 Nov 2026 01:09:20 +0100	[thread overview]
Message-ID: <87fqx8tej3.ffs@fw13> (raw)
In-Reply-To: <20261110-aplic-affinity-fix-v2-2-6c143b8b4e8c@linux.dev>

On Tue, Nov 10 2026 at 12:06, Troy Mitchell wrote:

> IMSIC rejects an affinity change with -EBUSY while a previous vector
> move is still in flight, and the IRQ core then records the new mask as
> pending. The change is applied by irq_move_irq() in the IMSIC irq_ack
> callback, but level-triggered APLIC MSI interrupts are handled by
> handle_fasteoi_irq(), which never calls irq_ack.
>
> The pending change is therefore never applied. While it is pending,
> later affinity changes only update the pending mask, so the interrupt
> stays on its old CPU.
>
> Use handle_fasteoi_ack_irq() for level-triggered sources. It acks the
> interrupt before invoking the handler, so a pending affinity change is
> applied on the next interrupt, and the EOI retrigger then targets the
> new CPU.

Smart!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-11-11  0:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 12:06 [PATCH v2 0/2] irqchip/riscv-aplic: Use trigger specific flow handlers in MSI mode Troy Mitchell
2026-11-10 12:06 ` Troy Mitchell
2026-11-10 12:06 ` [PATCH v2 1/2] irqchip/riscv-aplic: Use handle_edge_irq() for edge-triggered MSI sources Troy Mitchell
2026-11-10 12:06   ` Troy Mitchell
2026-11-11  0:07   ` Thomas Gleixner
2026-11-11  0:07     ` Thomas Gleixner
2026-11-11  1:11     ` Troy Mitchell
2026-11-11  1:11       ` Troy Mitchell
2026-11-10 12:06 ` [PATCH v2 2/2] irqchip/riscv-aplic: Apply pending affinity changes for level " Troy Mitchell
2026-11-10 12:06   ` Troy Mitchell
2026-11-11  0:09   ` Thomas Gleixner [this message]
2026-11-11  0:09     ` 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=87fqx8tej3.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=bjorn@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=radu@rendec.net \
    --cc=troy.mitchell@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.