Msi affinity support qli2.0 - #897
Conversation
Add infrastructure to redirect interrupt handler execution to a different CPU when the current CPU is not part of the interrupt's CPU affinity mask. This is primarily aimed at (de)multiplexed interrupts, where the child interrupt handler runs in the context of the parent interrupt handler, and therefore CPU affinity control for the child interrupt is typically not available. With the new infrastructure, the child interrupt is allowed to freely change its affinity setting, independently of the parent. If the interrupt handler happens to be triggered on an "incompatible" CPU (a CPU that's not part of the child interrupt's affinity mask), the handler is redirected and runs in IRQ work context on a "compatible" CPU. No functional change is being made to any existing irqchip driver, and irqchip drivers must be explicitly modified to use the newly added infrastructure to support interrupt redirection. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-2-rrendec@redhat.com (cherry picked from commit fcc1d0d)
Code cleanup with no functional changes. These changes were originally made by Thomas Gleixner (see Link tag below) in a patch that was never submitted as is. Other parts of that patch were eventually submitted as commit 8e71711 ("PCI: dwc: Switch to msi_create_parent_irq_domain()") and the remaining parts are the code cleanup changes: - Use guard()/scoped_guard() instead of open-coded lock/unlock. - Return void in a few functions whose return value is never used. - Simplify dw_handle_msi_irq() by using for_each_set_bit(). One notable deviation from the original patch is that it reverts back to a simple 1 by 1 iteration over the controllers inside dw_handle_msi_irq. The reason is that with the original changes, the IRQ offset was calculated incorrectly. This prepares the ground for enabling MSI affinity support, which was originally part of that same series that Thomas Gleixner prepared. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-3-rrendec@redhat.com (cherry picked from commit f187509)
Leverage the interrupt redirection infrastructure to enable CPU affinity support for MSI interrupts. Since the parent interrupt affinity cannot be changed, affinity control for the child interrupt (MSI) is achieved by redirecting the handler to run in IRQ work context on the target CPU. This patch was originally prepared by Thomas Gleixner (see Link tag below) in a patch series that was never submitted as is, and only parts of that series have made it upstream so far. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-4-rrendec@redhat.com (cherry picked from commit eaf290c)
For redirected interrupts, irq_chip_redirect_set_affinity() does not
update the effective affinity mask, which then triggers the warning in
irq_validate_effective_affinity(). Also, because the effective affinity
mask is empty, the cpumask_test_cpu(smp_processor_id(), m) condition in
demux_redirect_remote() is always false, and the interrupt is always
redirected, even if it's already running on the target CPU.
Set the effective affinity mask to be the same as the requested affinity
mask. It's worth noting that irq_do_set_affinity() filters out offline
CPUs before calling chip->irq_set_affinity() (unless `force` is set), so
the mask passed to irq_chip_redirect_set_affinity() is already filtered.
The solution is not ideal because it may lie about the effective
affinity of the demultiplexed ("child") interrupt. If the requested
affinity mask includes multiple CPUs, the effective affinity, in
reality, is the intersection between the requested mask and the
demultiplexing ("parent") interrupt's effective affinity mask, plus
the first CPU in the requested mask.
Accurately describing the effective affinity of the demultiplexed
interrupt is not trivial because it requires keeping track of the
demultiplexing interrupt's effective affinity. That is tricky in the
context of CPU hot(un)plugging, where interrupt migration ordering is
not guaranteed. The solution in the initial version of the fixed patch,
which stored the first CPU of the demultiplexing interrupt's effective
affinity in the `target_cpu` field, has its own drawbacks and
limitations.
Fixes: fcc1d0d ("genirq: Add interrupt redirection infrastructure")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260112211402.2927336-1-rrendec@redhat.com
Closes: https://lore.kernel.org/all/44509520-f29b-4b8a-8986-5eae3e022eb7@nvidia.com/
(cherry picked from commit df43971)
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
PR #897 — validate-patchPR: #897
Final Summary
|
PR #897 — checker-log-analyzerPR: #897
Detailed report: Full report
|
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
2 similar comments
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
3 participants
### MSI Affinity Support for DWC PCIe (backport)
Summary
Backports the upstream interrupt redirection infrastructure and enables CPU affinity control for MSI interrupts on DesignWare (DWC) PCIe controllers. On DWC, MSIs are demultiplexed from a single parent interrupt whose affinity cannot be changed, so per-MSI affinity was previously unavailable. This series adds generic genirq support to redirect a child interrupt's handler to run in IRQ-work context on a CPU within its affinity mask, and wires the DWC host driver up to use it.
https://patch.msgid.link/20251128212055.1409093-2-rrendec@redhat.com
https://patch.msgid.link/20251128212055.1409093-3-rrendec@redhat.com
https://patch.msgid.link/20251128212055.1409093-4-rrendec@redhat.com
https://patch.msgid.link/20260112211402.2927336-1-rrendec@redhat.com
Files changed
drivers/pci/controller/dwc/pcie-designware-host.c | 127 +++++++-------
drivers/pci/controller/dwc/pcie-designware.h | 7 +-
include/linux/irq.h | 10 +
include/linux/irqdesc.h | 17 +-
kernel/irq/chip.c | 24 +-
kernel/irq/irqdesc.c | 86 +++++++-
kernel/irq/manage.c | 15 +-
7 files changed, 206 insertions(+), 80 deletions(-)