This series aims to improve IPI support in Linux RISC-V in following ways:
1) Treat IPIs as normal per-CPU interrupts instead of having custom RISC-V
specific hooks. This also makes Linux RISC-V IPI support aligned with
other architectures.
2) Remote TLB flushes and icache flushes should prefer local IPIs instead
of SBI calls whenever we have specialized hardware (such as RISC-V AIA
IMSIC and RISC-V SWI) which allows S-mode software to directly inject
IPIs without any assistance from M-mode runtime firmware.
These patches were originally part of the "Linux RISC-V ACLINT Support"
series but this now a separate series so that it can be merged independently
of the "Linux RISC-V ACLINT Support" series.
(Refer, https://lore.kernel.org/lkml/[email protected]/)
These patches are also a preparatory patches for the up-coming:
1) Linux RISC-V AIA support
2) Linux RISC-V SWI support
These patches can also be found in riscv_ipi_imp_v16 branch at:
https://github.com/avpatel/linux.git
Changes since v15:
- Rebased on Linux-6.2-rc2
- Added Reviewed-by and Tested-by tags to some of the patches.
Changes since v14:
- Minor fixes in commit description of PATCH3 (as suggested by tglx)
- Don't disable parent IPI when CPU goes offline for SBI IPI driver and
CLINT driver in PATCH4.
- Include Apple AIC driver changes from Marc Z as PATCH9
Changes since v13:
- Included changes suggested by Marc Z in PATCH3
- Use chained handlers in PATCH4
- Added new PATCH8 to have empty irq_eoi() in RISC-V INTC driver. This
avoids the unnecessary mask/unmask dance at time of handling interrupts.
Changes since v12:
- Rebased on Linux-6.1-rc7
- Bring-back the IPI optimization in ipi_mux_send_mask() for PATCH3
- Call ipi_mux_send() for one target CPU at a time in PATCH3
Changes since v11:
- Removed ipi_mux_pre/post_handle() callbacks in PATCH3
- Removed sturct ipi_mux_ops in PATCH3
- Removed parent_virq and data pointer from everywhere in PATCH3
- Removed struct ipi_mux_control in PATCH3
- Improved function signature of ipi_mux_send() callback in PATCH3
- Used unsigned type with atomic operation in PATCH3
Changes since v10:
- Rebased on Linux-6.1-rc5
- Drop the "!(pending & ibit)" check in ipi_mux_send_mask() of PATCH3
- Disable local interrupts in ipi_mux_send_mask() of PATCH3 because we
can be preempted while using a per-CPU temporary variable.
Changes since v9:
- Rebased on Linux-6.1-rc3
- Updated header comment block of ipi-mux.c in PATCH3
- Use a struct for global data of ipi-mux.c in PATCH3
- Add per-CPU temp cpumask for sending IPIs in PATCH3
- Drop the use of fwspec in PATCH3
- Use static key for ipi_mux_pre_handle() and ipi_mux_post_handle()
in PATCH3
- Remove redundant pr_warn_ratelimited() called by ipi_mux_process()
in PATCH3
- Remove CPUHP thingy from ipi_mux_create() in PATCH3
Changes since v8:
- Rebased on Linux-6.0-rc3
- Use dummy percpu data as parameter for request_percpu_irq() in PATCH4.
Changes since v7:
- Rebased on Linux-6.0-rc1
- Use atomic operations to track per-CPU pending and enabled IPIs in PATCH3.
(Note: this is inspired from IPI muxing implemented in
drivers/irqchip/irq-apple-aic.c)
- Made "struct ipi_mux_ops" (added by PATCH3) flexible so that
drivers/irqchip/irq-apple-aic.c can adopt it in future.
Changes since v6:
- Rebased on Linux-5.19-rc7
- Added documentation for struct ipi_mux_ops in PATCH3
- Dropped dummy irq_mask()/unmask() in PATCH3
- Added const for "ipi_mux_chip" in PATCH3
- Removed "type" initialization from ipi_mux_domain_alloc() in PATCH3
- Dropped translate() from "ipi_mux_domain_ops" in PATCH3
- Improved barrier documentation in ipi_mux_process() of PATCH3
- Added percpu check in ipi_mux_create() for parent_virq of PATCH3
- Added nr_ipi parameter in ipi_mux_create() of PATCH3
Changes since v5:
- Rebased on Linux-5.18-rc3
- Used kernel doc style in PATCH3
- Removed redundant loop in ipi_mux_process() of PATCH3
- Removed "RISC-V" prefix form ipi_mux_chip.name of PATCH3
- Removed use of "this patch" in PATCH3 commit description
- Addressed few other nit comments in PATCH3
Changes since v4:
- Rebased on Linux-5.17
- Includes new PATCH3 which adds mechanism to multiplex a single HW IPI
Changes since v3:
- Rebased on Linux-5.17-rc6
- Updated PATCH2 to not export riscv_set_intc_hwnode_fn()
- Simplified riscv_intc_hwnode() in PATCH2
Changes since v2:
- Rebased on Linux-5.17-rc4
- Updated PATCH2 to not create synthetic INTC fwnode and instead provide
a function which allows drivers to directly discover INTC fwnode
Changes since v1:
- Use synthetic fwnode for INTC instead of irq_set_default_host() in PATCH2
Anup Patel (8):
RISC-V: Clear SIP bit only when using SBI IPI operations
irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode
genirq: Add mechanism to multiplex a single HW IPI
RISC-V: Treat IPIs as normal Linux IRQs
RISC-V: Allow marking IPIs as suitable for remote FENCEs
RISC-V: Use IPIs for remote TLB flush when possible
RISC-V: Use IPIs for remote icache flush when possible
irqchip/riscv-intc: Add empty irq_eoi() for chained irq handlers
Marc Zyngier (1):
irqchip/apple-aic: Move over to core ipi-mux
arch/riscv/Kconfig | 2 +
arch/riscv/include/asm/irq.h | 4 +
arch/riscv/include/asm/sbi.h | 9 +-
arch/riscv/include/asm/smp.h | 49 +++++--
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/cpu-hotplug.c | 3 +-
arch/riscv/kernel/irq.c | 21 ++-
arch/riscv/kernel/sbi-ipi.c | 77 +++++++++++
arch/riscv/kernel/sbi.c | 100 +++------------
arch/riscv/kernel/smp.c | 171 ++++++++++++------------
arch/riscv/kernel/smpboot.c | 5 +-
arch/riscv/mm/cacheflush.c | 5 +-
arch/riscv/mm/tlbflush.c | 93 +++++++++++---
drivers/clocksource/timer-clint.c | 65 +++++++---
drivers/irqchip/Kconfig | 2 +
drivers/irqchip/irq-apple-aic.c | 161 ++---------------------
drivers/irqchip/irq-riscv-intc.c | 71 ++++++----
include/linux/irq.h | 3 +
kernel/irq/Kconfig | 5 +
kernel/irq/Makefile | 1 +
kernel/irq/ipi-mux.c | 207 ++++++++++++++++++++++++++++++
21 files changed, 654 insertions(+), 401 deletions(-)
create mode 100644 arch/riscv/kernel/sbi-ipi.c
create mode 100644 kernel/irq/ipi-mux.c
--
2.34.1
If we have specialized interrupt controller (such as AIA IMSIC) which
allows supervisor mode to directly inject IPIs without any assistance
from M-mode or HS-mode then using such specialized interrupt controller,
we can do remote TLB flushes directly from supervisor mode instead of
using the SBI RFENCE calls.
This patch extends remote TLB flush functions to use supervisor mode
IPIs whenever direct supervisor mode IPIs.are supported by interrupt
controller.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Atish Patra <[email protected]>
---
arch/riscv/mm/tlbflush.c | 93 +++++++++++++++++++++++++++++++++-------
1 file changed, 78 insertions(+), 15 deletions(-)
diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
index ce7dfc81bb3f..91078377344d 100644
--- a/arch/riscv/mm/tlbflush.c
+++ b/arch/riscv/mm/tlbflush.c
@@ -7,14 +7,62 @@
#include <asm/mmu_context.h>
#include <asm/tlbflush.h>
+static inline void local_flush_tlb_range(unsigned long start,
+ unsigned long size, unsigned long stride)
+{
+ if (size <= stride)
+ local_flush_tlb_page(start);
+ else
+ local_flush_tlb_all();
+}
+
+static inline void local_flush_tlb_range_asid(unsigned long start,
+ unsigned long size, unsigned long stride, unsigned long asid)
+{
+ if (size <= stride)
+ local_flush_tlb_page_asid(start, asid);
+ else
+ local_flush_tlb_all_asid(asid);
+}
+
+static void __ipi_flush_tlb_all(void *info)
+{
+ local_flush_tlb_all();
+}
+
void flush_tlb_all(void)
{
- sbi_remote_sfence_vma(NULL, 0, -1);
+ if (riscv_use_ipi_for_rfence())
+ on_each_cpu(__ipi_flush_tlb_all, NULL, 1);
+ else
+ sbi_remote_sfence_vma(NULL, 0, -1);
+}
+
+struct flush_tlb_range_data {
+ unsigned long asid;
+ unsigned long start;
+ unsigned long size;
+ unsigned long stride;
+};
+
+static void __ipi_flush_tlb_range_asid(void *info)
+{
+ struct flush_tlb_range_data *d = info;
+
+ local_flush_tlb_range_asid(d->start, d->size, d->stride, d->asid);
+}
+
+static void __ipi_flush_tlb_range(void *info)
+{
+ struct flush_tlb_range_data *d = info;
+
+ local_flush_tlb_range(d->start, d->size, d->stride);
}
-static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
- unsigned long size, unsigned long stride)
+static void __flush_tlb_range(struct mm_struct *mm, unsigned long start,
+ unsigned long size, unsigned long stride)
{
+ struct flush_tlb_range_data ftd;
struct cpumask *pmask = &mm->context.tlb_stale_mask;
struct cpumask *cmask = mm_cpumask(mm);
unsigned int cpuid;
@@ -39,19 +87,34 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
cpumask_andnot(pmask, pmask, cmask);
if (broadcast) {
- sbi_remote_sfence_vma_asid(cmask, start, size, asid);
- } else if (size <= stride) {
- local_flush_tlb_page_asid(start, asid);
+ if (riscv_use_ipi_for_rfence()) {
+ ftd.asid = asid;
+ ftd.start = start;
+ ftd.size = size;
+ ftd.stride = stride;
+ on_each_cpu_mask(cmask,
+ __ipi_flush_tlb_range_asid,
+ &ftd, 1);
+ } else
+ sbi_remote_sfence_vma_asid(cmask,
+ start, size, asid);
} else {
- local_flush_tlb_all_asid(asid);
+ local_flush_tlb_range_asid(start, size, stride, asid);
}
} else {
if (broadcast) {
- sbi_remote_sfence_vma(cmask, start, size);
- } else if (size <= stride) {
- local_flush_tlb_page(start);
+ if (riscv_use_ipi_for_rfence()) {
+ ftd.asid = 0;
+ ftd.start = start;
+ ftd.size = size;
+ ftd.stride = stride;
+ on_each_cpu_mask(cmask,
+ __ipi_flush_tlb_range,
+ &ftd, 1);
+ } else
+ sbi_remote_sfence_vma(cmask, start, size);
} else {
- local_flush_tlb_all();
+ local_flush_tlb_range(start, size, stride);
}
}
@@ -60,23 +123,23 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
void flush_tlb_mm(struct mm_struct *mm)
{
- __sbi_tlb_flush_range(mm, 0, -1, PAGE_SIZE);
+ __flush_tlb_range(mm, 0, -1, PAGE_SIZE);
}
void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)
{
- __sbi_tlb_flush_range(vma->vm_mm, addr, PAGE_SIZE, PAGE_SIZE);
+ __flush_tlb_range(vma->vm_mm, addr, PAGE_SIZE, PAGE_SIZE);
}
void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end)
{
- __sbi_tlb_flush_range(vma->vm_mm, start, end - start, PAGE_SIZE);
+ __flush_tlb_range(vma->vm_mm, start, end - start, PAGE_SIZE);
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
void flush_pmd_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end)
{
- __sbi_tlb_flush_range(vma->vm_mm, start, end - start, PMD_SIZE);
+ __flush_tlb_range(vma->vm_mm, start, end - start, PMD_SIZE);
}
#endif
--
2.34.1
All RISC-V platforms have a single HW IPI provided by the INTC local
interrupt controller. The HW method to trigger INTC IPI can be through
external irqchip (e.g. RISC-V AIA), through platform specific device
(e.g. SiFive CLINT timer), or through firmware (e.g. SBI IPI call).
To support multiple IPIs on RISC-V, add a generic IPI multiplexing
mechanism which help us create multiple virtual IPIs using a single
HW IPI. This generic IPI multiplexing is inspired by the Apple AIC
irqchip driver and it is shared by various RISC-V irqchip drivers.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Hector Martin <[email protected]>
Tested-by: Hector Martin <[email protected]>
---
include/linux/irq.h | 3 +
kernel/irq/Kconfig | 5 ++
kernel/irq/Makefile | 1 +
kernel/irq/ipi-mux.c | 207 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 216 insertions(+)
create mode 100644 kernel/irq/ipi-mux.c
diff --git a/include/linux/irq.h b/include/linux/irq.h
index c3eb89606c2b..b1b28affb32a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1266,6 +1266,9 @@ int __ipi_send_mask(struct irq_desc *desc, const struct cpumask *dest);
int ipi_send_single(unsigned int virq, unsigned int cpu);
int ipi_send_mask(unsigned int virq, const struct cpumask *dest);
+void ipi_mux_process(void);
+int ipi_mux_create(unsigned int nr_ipi, void (*mux_send)(unsigned int cpu));
+
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
/*
* Registers a generic IRQ handling function as the top-level IRQ handler in
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index b64c44ae4c25..2531f3496ab6 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -86,6 +86,11 @@ config GENERIC_IRQ_IPI
depends on SMP
select IRQ_DOMAIN_HIERARCHY
+# Generic IRQ IPI Mux support
+config GENERIC_IRQ_IPI_MUX
+ bool
+ depends on SMP
+
# Generic MSI hierarchical interrupt domain support
config GENERIC_MSI_IRQ
bool
diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
index b4f53717d143..f19d3080bf11 100644
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_GENERIC_IRQ_MIGRATION) += cpuhotplug.o
obj-$(CONFIG_PM_SLEEP) += pm.o
obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o
obj-$(CONFIG_GENERIC_IRQ_IPI) += ipi.o
+obj-$(CONFIG_GENERIC_IRQ_IPI_MUX) += ipi-mux.o
obj-$(CONFIG_SMP) += affinity.o
obj-$(CONFIG_GENERIC_IRQ_DEBUGFS) += debugfs.o
obj-$(CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR) += matrix.o
diff --git a/kernel/irq/ipi-mux.c b/kernel/irq/ipi-mux.c
new file mode 100644
index 000000000000..3a403c3a785d
--- /dev/null
+++ b/kernel/irq/ipi-mux.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Multiplex several virtual IPIs over a single HW IPI.
+ *
+ * Copyright The Asahi Linux Contributors
+ * Copyright (c) 2022 Ventana Micro Systems Inc.
+ */
+
+#define pr_fmt(fmt) "ipi-mux: " fmt
+#include <linux/cpu.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/jump_label.h>
+#include <linux/percpu.h>
+#include <linux/smp.h>
+
+struct ipi_mux_cpu {
+ atomic_t enable;
+ atomic_t bits;
+};
+
+static struct ipi_mux_cpu __percpu *ipi_mux_pcpu;
+static struct irq_domain *ipi_mux_domain;
+static void (*ipi_mux_send)(unsigned int cpu);
+
+static void ipi_mux_mask(struct irq_data *d)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+
+ atomic_andnot(BIT(irqd_to_hwirq(d)), &icpu->enable);
+}
+
+static void ipi_mux_unmask(struct irq_data *d)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+ u32 ibit = BIT(irqd_to_hwirq(d));
+
+ atomic_or(ibit, &icpu->enable);
+
+ /*
+ * The atomic_or() above must complete before the atomic_read()
+ * below to avoid racing ipi_mux_send_mask().
+ */
+ smp_mb__after_atomic();
+
+ /* If a pending IPI was unmasked, raise a parent IPI immediately. */
+ if (atomic_read(&icpu->bits) & ibit)
+ ipi_mux_send(smp_processor_id());
+}
+
+static void ipi_mux_send_mask(struct irq_data *d, const struct cpumask *mask)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+ u32 ibit = BIT(irqd_to_hwirq(d));
+ unsigned long pending;
+ int cpu;
+
+ for_each_cpu(cpu, mask) {
+ icpu = per_cpu_ptr(ipi_mux_pcpu, cpu);
+
+ /*
+ * This sequence is the mirror of the one in ipi_mux_unmask();
+ * see the comment there. Additionally, release semantics
+ * ensure that the vIPI flag set is ordered after any shared
+ * memory accesses that precede it. This therefore also pairs
+ * with the atomic_fetch_andnot in ipi_mux_process().
+ */
+ pending = atomic_fetch_or_release(ibit, &icpu->bits);
+
+ /*
+ * The atomic_fetch_or_release() above must complete
+ * before the atomic_read() below to avoid racing with
+ * ipi_mux_unmask().
+ */
+ smp_mb__after_atomic();
+
+ /*
+ * The flag writes must complete before the physical IPI is
+ * issued to another CPU. This is implied by the control
+ * dependency on the result of atomic_read() below, which is
+ * itself already ordered after the vIPI flag write.
+ */
+ if (!(pending & ibit) && (atomic_read(&icpu->enable) & ibit))
+ ipi_mux_send(cpu);
+ }
+}
+
+static const struct irq_chip ipi_mux_chip = {
+ .name = "IPI Mux",
+ .irq_mask = ipi_mux_mask,
+ .irq_unmask = ipi_mux_unmask,
+ .ipi_send_mask = ipi_mux_send_mask,
+};
+
+static int ipi_mux_domain_alloc(struct irq_domain *d, unsigned int virq,
+ unsigned int nr_irqs, void *arg)
+{
+ int i;
+
+ for (i = 0; i < nr_irqs; i++) {
+ irq_set_percpu_devid(virq + i);
+ irq_domain_set_info(d, virq + i, i, &ipi_mux_chip, NULL,
+ handle_percpu_devid_irq, NULL, NULL);
+ }
+
+ return 0;
+}
+
+static const struct irq_domain_ops ipi_mux_domain_ops = {
+ .alloc = ipi_mux_domain_alloc,
+ .free = irq_domain_free_irqs_top,
+};
+
+/**
+ * ipi_mux_process - Process multiplexed virtual IPIs
+ */
+void ipi_mux_process(void)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+ irq_hw_number_t hwirq;
+ unsigned long ipis;
+ unsigned int en;
+
+ /*
+ * Reading enable mask does not need to be ordered as long as
+ * this function is called from interrupt handler because only
+ * the CPU itself can change it's own enable mask.
+ */
+ en = atomic_read(&icpu->enable);
+
+ /*
+ * Clear the IPIs we are about to handle. This pairs with the
+ * atomic_fetch_or_release() in ipi_mux_send_mask().
+ */
+ ipis = atomic_fetch_andnot(en, &icpu->bits) & en;
+
+ for_each_set_bit(hwirq, &ipis, BITS_PER_TYPE(int))
+ generic_handle_domain_irq(ipi_mux_domain, hwirq);
+}
+
+/**
+ * ipi_mux_create - Create virtual IPIs multiplexed on top of a single
+ * parent IPI.
+ * @nr_ipi: number of virtual IPIs to create. This should
+ * be <= BITS_PER_TYPE(int)
+ * @mux_send: callback to trigger parent IPI for a particular CPU
+ *
+ * Returns first virq of the newly created virtual IPIs upon success
+ * or <=0 upon failure
+ */
+int ipi_mux_create(unsigned int nr_ipi, void (*mux_send)(unsigned int cpu))
+{
+ struct fwnode_handle *fwnode;
+ struct irq_domain *domain;
+ int rc;
+
+ if (ipi_mux_domain)
+ return -EEXIST;
+
+ if (BITS_PER_TYPE(int) < nr_ipi || !mux_send)
+ return -EINVAL;
+
+ ipi_mux_pcpu = alloc_percpu(typeof(*ipi_mux_pcpu));
+ if (!ipi_mux_pcpu)
+ return -ENOMEM;
+
+ fwnode = irq_domain_alloc_named_fwnode("IPI-Mux");
+ if (!fwnode) {
+ pr_err("unable to create IPI Mux fwnode\n");
+ rc = -ENOMEM;
+ goto fail_free_cpu;
+ }
+
+ domain = irq_domain_create_linear(fwnode, nr_ipi,
+ &ipi_mux_domain_ops, NULL);
+ if (!domain) {
+ pr_err("unable to add IPI Mux domain\n");
+ rc = -ENOMEM;
+ goto fail_free_fwnode;
+ }
+
+ domain->flags |= IRQ_DOMAIN_FLAG_IPI_SINGLE;
+ irq_domain_update_bus_token(domain, DOMAIN_BUS_IPI);
+
+ rc = __irq_domain_alloc_irqs(domain, -1, nr_ipi,
+ NUMA_NO_NODE, NULL, false, NULL);
+ if (rc <= 0) {
+ pr_err("unable to alloc IRQs from IPI Mux domain\n");
+ goto fail_free_domain;
+ }
+
+ ipi_mux_domain = domain;
+ ipi_mux_send = mux_send;
+
+ return rc;
+
+fail_free_domain:
+ irq_domain_remove(domain);
+fail_free_fwnode:
+ irq_domain_free_fwnode(fwnode);
+fail_free_cpu:
+ free_percpu(ipi_mux_pcpu);
+ return rc;
+}
--
2.34.1
If we have specialized interrupt controller (such as AIA IMSIC) which
allows supervisor mode to directly inject IPIs without any assistance
from M-mode or HS-mode then using such specialized interrupt controller,
we can do remote icache flushe directly from supervisor mode instead of
using the SBI RFENCE calls.
This patch extends remote icache flush functions to use supervisor mode
IPIs whenever direct supervisor mode IPIs.are supported by interrupt
controller.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Atish Patra <[email protected]>
---
arch/riscv/mm/cacheflush.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
index 3cc07ed45aeb..b093727494eb 100644
--- a/arch/riscv/mm/cacheflush.c
+++ b/arch/riscv/mm/cacheflush.c
@@ -19,7 +19,7 @@ void flush_icache_all(void)
{
local_flush_icache_all();
- if (IS_ENABLED(CONFIG_RISCV_SBI))
+ if (IS_ENABLED(CONFIG_RISCV_SBI) && !riscv_use_ipi_for_rfence())
sbi_remote_fence_i(NULL);
else
on_each_cpu(ipi_remote_fence_i, NULL, 1);
@@ -67,7 +67,8 @@ void flush_icache_mm(struct mm_struct *mm, bool local)
* with flush_icache_deferred().
*/
smp_mb();
- } else if (IS_ENABLED(CONFIG_RISCV_SBI)) {
+ } else if (IS_ENABLED(CONFIG_RISCV_SBI) &&
+ !riscv_use_ipi_for_rfence()) {
sbi_remote_fence_i(&others);
} else {
on_each_cpu_mask(&others, ipi_remote_fence_i, NULL, 1);
--
2.34.1
We add empty irq_eoi() in RISC-V INTC driver for child irqchip
drivers (such as PLIC, SBI IPI, CLINT, APLIC, IMSIC, etc) which
implement chained handlers for parent per-HART local interrupts.
This hels us avoid unnecessary mask/unmask of per-HART local
interrupts at the time of handling interrupts.
Signed-off-by: Anup Patel <[email protected]>
---
drivers/irqchip/irq-riscv-intc.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
index 784d25645704..f229e3e66387 100644
--- a/drivers/irqchip/irq-riscv-intc.c
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -46,10 +46,27 @@ static void riscv_intc_irq_unmask(struct irq_data *d)
csr_set(CSR_IE, BIT(d->hwirq));
}
+static void riscv_intc_irq_eoi(struct irq_data *d)
+{
+ /*
+ * The RISC-V INTC driver uses handle_percpu_devid_irq() flow
+ * for the per-HART local interrupts and child irqchip drivers
+ * (such as PLIC, SBI IPI, CLINT, APLIC, IMSIC, etc) implement
+ * chained handlers for the per-HART local interrupts.
+ *
+ * In the absence of irq_eoi(), the chained_irq_enter() and
+ * chained_irq_exit() functions (used by child irqchip drivers)
+ * will do unnecessary mask/unmask of per-HART local interrupts
+ * at the time of handling interrupts. To avoid this, we provide
+ * an empty irq_eoi() callback for RISC-V INTC irqchip.
+ */
+}
+
static struct irq_chip riscv_intc_chip = {
.name = "RISC-V INTC",
.irq_mask = riscv_intc_irq_mask,
.irq_unmask = riscv_intc_irq_unmask,
+ .irq_eoi = riscv_intc_irq_eoi,
};
static int riscv_intc_domain_map(struct irq_domain *d, unsigned int irq,
--
2.34.1
Hi Marc,
On Tue, Jan 3, 2023 at 7:42 PM Anup Patel <[email protected]> wrote:
>
> This series aims to improve IPI support in Linux RISC-V in following ways:
> 1) Treat IPIs as normal per-CPU interrupts instead of having custom RISC-V
> specific hooks. This also makes Linux RISC-V IPI support aligned with
> other architectures.
> 2) Remote TLB flushes and icache flushes should prefer local IPIs instead
> of SBI calls whenever we have specialized hardware (such as RISC-V AIA
> IMSIC and RISC-V SWI) which allows S-mode software to directly inject
> IPIs without any assistance from M-mode runtime firmware.
>
> These patches were originally part of the "Linux RISC-V ACLINT Support"
> series but this now a separate series so that it can be merged independently
> of the "Linux RISC-V ACLINT Support" series.
> (Refer, https://lore.kernel.org/lkml/[email protected]/)
>
> These patches are also a preparatory patches for the up-coming:
> 1) Linux RISC-V AIA support
> 2) Linux RISC-V SWI support
>
> These patches can also be found in riscv_ipi_imp_v16 branch at:
> https://github.com/avpatel/linux.git
>
> Changes since v15:
> - Rebased on Linux-6.2-rc2
> - Added Reviewed-by and Tested-by tags to some of the patches.
>
> Changes since v14:
> - Minor fixes in commit description of PATCH3 (as suggested by tglx)
> - Don't disable parent IPI when CPU goes offline for SBI IPI driver and
> CLINT driver in PATCH4.
> - Include Apple AIC driver changes from Marc Z as PATCH9
>
> Changes since v13:
> - Included changes suggested by Marc Z in PATCH3
> - Use chained handlers in PATCH4
> - Added new PATCH8 to have empty irq_eoi() in RISC-V INTC driver. This
> avoids the unnecessary mask/unmask dance at time of handling interrupts.
>
> Changes since v12:
> - Rebased on Linux-6.1-rc7
> - Bring-back the IPI optimization in ipi_mux_send_mask() for PATCH3
> - Call ipi_mux_send() for one target CPU at a time in PATCH3
>
> Changes since v11:
> - Removed ipi_mux_pre/post_handle() callbacks in PATCH3
> - Removed sturct ipi_mux_ops in PATCH3
> - Removed parent_virq and data pointer from everywhere in PATCH3
> - Removed struct ipi_mux_control in PATCH3
> - Improved function signature of ipi_mux_send() callback in PATCH3
> - Used unsigned type with atomic operation in PATCH3
>
> Changes since v10:
> - Rebased on Linux-6.1-rc5
> - Drop the "!(pending & ibit)" check in ipi_mux_send_mask() of PATCH3
> - Disable local interrupts in ipi_mux_send_mask() of PATCH3 because we
> can be preempted while using a per-CPU temporary variable.
>
> Changes since v9:
> - Rebased on Linux-6.1-rc3
> - Updated header comment block of ipi-mux.c in PATCH3
> - Use a struct for global data of ipi-mux.c in PATCH3
> - Add per-CPU temp cpumask for sending IPIs in PATCH3
> - Drop the use of fwspec in PATCH3
> - Use static key for ipi_mux_pre_handle() and ipi_mux_post_handle()
> in PATCH3
> - Remove redundant pr_warn_ratelimited() called by ipi_mux_process()
> in PATCH3
> - Remove CPUHP thingy from ipi_mux_create() in PATCH3
>
> Changes since v8:
> - Rebased on Linux-6.0-rc3
> - Use dummy percpu data as parameter for request_percpu_irq() in PATCH4.
>
> Changes since v7:
> - Rebased on Linux-6.0-rc1
> - Use atomic operations to track per-CPU pending and enabled IPIs in PATCH3.
> (Note: this is inspired from IPI muxing implemented in
> drivers/irqchip/irq-apple-aic.c)
> - Made "struct ipi_mux_ops" (added by PATCH3) flexible so that
> drivers/irqchip/irq-apple-aic.c can adopt it in future.
>
> Changes since v6:
> - Rebased on Linux-5.19-rc7
> - Added documentation for struct ipi_mux_ops in PATCH3
> - Dropped dummy irq_mask()/unmask() in PATCH3
> - Added const for "ipi_mux_chip" in PATCH3
> - Removed "type" initialization from ipi_mux_domain_alloc() in PATCH3
> - Dropped translate() from "ipi_mux_domain_ops" in PATCH3
> - Improved barrier documentation in ipi_mux_process() of PATCH3
> - Added percpu check in ipi_mux_create() for parent_virq of PATCH3
> - Added nr_ipi parameter in ipi_mux_create() of PATCH3
>
> Changes since v5:
> - Rebased on Linux-5.18-rc3
> - Used kernel doc style in PATCH3
> - Removed redundant loop in ipi_mux_process() of PATCH3
> - Removed "RISC-V" prefix form ipi_mux_chip.name of PATCH3
> - Removed use of "this patch" in PATCH3 commit description
> - Addressed few other nit comments in PATCH3
>
> Changes since v4:
> - Rebased on Linux-5.17
> - Includes new PATCH3 which adds mechanism to multiplex a single HW IPI
>
> Changes since v3:
> - Rebased on Linux-5.17-rc6
> - Updated PATCH2 to not export riscv_set_intc_hwnode_fn()
> - Simplified riscv_intc_hwnode() in PATCH2
>
> Changes since v2:
> - Rebased on Linux-5.17-rc4
> - Updated PATCH2 to not create synthetic INTC fwnode and instead provide
> a function which allows drivers to directly discover INTC fwnode
>
> Changes since v1:
> - Use synthetic fwnode for INTC instead of irq_set_default_host() in PATCH2
>
> Anup Patel (8):
> RISC-V: Clear SIP bit only when using SBI IPI operations
> irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode
> genirq: Add mechanism to multiplex a single HW IPI
> RISC-V: Treat IPIs as normal Linux IRQs
> RISC-V: Allow marking IPIs as suitable for remote FENCEs
> RISC-V: Use IPIs for remote TLB flush when possible
> RISC-V: Use IPIs for remote icache flush when possible
> irqchip/riscv-intc: Add empty irq_eoi() for chained irq handlers
>
> Marc Zyngier (1):
> irqchip/apple-aic: Move over to core ipi-mux
>
> arch/riscv/Kconfig | 2 +
> arch/riscv/include/asm/irq.h | 4 +
> arch/riscv/include/asm/sbi.h | 9 +-
> arch/riscv/include/asm/smp.h | 49 +++++--
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/cpu-hotplug.c | 3 +-
> arch/riscv/kernel/irq.c | 21 ++-
> arch/riscv/kernel/sbi-ipi.c | 77 +++++++++++
> arch/riscv/kernel/sbi.c | 100 +++------------
> arch/riscv/kernel/smp.c | 171 ++++++++++++------------
> arch/riscv/kernel/smpboot.c | 5 +-
> arch/riscv/mm/cacheflush.c | 5 +-
> arch/riscv/mm/tlbflush.c | 93 +++++++++++---
> drivers/clocksource/timer-clint.c | 65 +++++++---
> drivers/irqchip/Kconfig | 2 +
> drivers/irqchip/irq-apple-aic.c | 161 ++---------------------
> drivers/irqchip/irq-riscv-intc.c | 71 ++++++----
> include/linux/irq.h | 3 +
> kernel/irq/Kconfig | 5 +
> kernel/irq/Makefile | 1 +
> kernel/irq/ipi-mux.c | 207 ++++++++++++++++++++++++++++++
> 21 files changed, 654 insertions(+), 401 deletions(-)
> create mode 100644 arch/riscv/kernel/sbi-ipi.c
> create mode 100644 kernel/irq/ipi-mux.c
>
> --
> 2.34.1
>
Friendly ping ?
Regards,
Anup
Hi Marc,
On Thu, Jan 12, 2023 at 5:47 PM Anup Patel <[email protected]> wrote:
>
> Hi Marc,
>
> On Tue, Jan 3, 2023 at 7:42 PM Anup Patel <[email protected]> wrote:
> >
> > This series aims to improve IPI support in Linux RISC-V in following ways:
> > 1) Treat IPIs as normal per-CPU interrupts instead of having custom RISC-V
> > specific hooks. This also makes Linux RISC-V IPI support aligned with
> > other architectures.
> > 2) Remote TLB flushes and icache flushes should prefer local IPIs instead
> > of SBI calls whenever we have specialized hardware (such as RISC-V AIA
> > IMSIC and RISC-V SWI) which allows S-mode software to directly inject
> > IPIs without any assistance from M-mode runtime firmware.
> >
> > These patches were originally part of the "Linux RISC-V ACLINT Support"
> > series but this now a separate series so that it can be merged independently
> > of the "Linux RISC-V ACLINT Support" series.
> > (Refer, https://lore.kernel.org/lkml/[email protected]/)
> >
> > These patches are also a preparatory patches for the up-coming:
> > 1) Linux RISC-V AIA support
> > 2) Linux RISC-V SWI support
> >
> > These patches can also be found in riscv_ipi_imp_v16 branch at:
> > https://github.com/avpatel/linux.git
> >
> > Changes since v15:
> > - Rebased on Linux-6.2-rc2
> > - Added Reviewed-by and Tested-by tags to some of the patches.
> >
> > Changes since v14:
> > - Minor fixes in commit description of PATCH3 (as suggested by tglx)
> > - Don't disable parent IPI when CPU goes offline for SBI IPI driver and
> > CLINT driver in PATCH4.
> > - Include Apple AIC driver changes from Marc Z as PATCH9
> >
> > Changes since v13:
> > - Included changes suggested by Marc Z in PATCH3
> > - Use chained handlers in PATCH4
> > - Added new PATCH8 to have empty irq_eoi() in RISC-V INTC driver. This
> > avoids the unnecessary mask/unmask dance at time of handling interrupts.
> >
> > Changes since v12:
> > - Rebased on Linux-6.1-rc7
> > - Bring-back the IPI optimization in ipi_mux_send_mask() for PATCH3
> > - Call ipi_mux_send() for one target CPU at a time in PATCH3
> >
> > Changes since v11:
> > - Removed ipi_mux_pre/post_handle() callbacks in PATCH3
> > - Removed sturct ipi_mux_ops in PATCH3
> > - Removed parent_virq and data pointer from everywhere in PATCH3
> > - Removed struct ipi_mux_control in PATCH3
> > - Improved function signature of ipi_mux_send() callback in PATCH3
> > - Used unsigned type with atomic operation in PATCH3
> >
> > Changes since v10:
> > - Rebased on Linux-6.1-rc5
> > - Drop the "!(pending & ibit)" check in ipi_mux_send_mask() of PATCH3
> > - Disable local interrupts in ipi_mux_send_mask() of PATCH3 because we
> > can be preempted while using a per-CPU temporary variable.
> >
> > Changes since v9:
> > - Rebased on Linux-6.1-rc3
> > - Updated header comment block of ipi-mux.c in PATCH3
> > - Use a struct for global data of ipi-mux.c in PATCH3
> > - Add per-CPU temp cpumask for sending IPIs in PATCH3
> > - Drop the use of fwspec in PATCH3
> > - Use static key for ipi_mux_pre_handle() and ipi_mux_post_handle()
> > in PATCH3
> > - Remove redundant pr_warn_ratelimited() called by ipi_mux_process()
> > in PATCH3
> > - Remove CPUHP thingy from ipi_mux_create() in PATCH3
> >
> > Changes since v8:
> > - Rebased on Linux-6.0-rc3
> > - Use dummy percpu data as parameter for request_percpu_irq() in PATCH4.
> >
> > Changes since v7:
> > - Rebased on Linux-6.0-rc1
> > - Use atomic operations to track per-CPU pending and enabled IPIs in PATCH3.
> > (Note: this is inspired from IPI muxing implemented in
> > drivers/irqchip/irq-apple-aic.c)
> > - Made "struct ipi_mux_ops" (added by PATCH3) flexible so that
> > drivers/irqchip/irq-apple-aic.c can adopt it in future.
> >
> > Changes since v6:
> > - Rebased on Linux-5.19-rc7
> > - Added documentation for struct ipi_mux_ops in PATCH3
> > - Dropped dummy irq_mask()/unmask() in PATCH3
> > - Added const for "ipi_mux_chip" in PATCH3
> > - Removed "type" initialization from ipi_mux_domain_alloc() in PATCH3
> > - Dropped translate() from "ipi_mux_domain_ops" in PATCH3
> > - Improved barrier documentation in ipi_mux_process() of PATCH3
> > - Added percpu check in ipi_mux_create() for parent_virq of PATCH3
> > - Added nr_ipi parameter in ipi_mux_create() of PATCH3
> >
> > Changes since v5:
> > - Rebased on Linux-5.18-rc3
> > - Used kernel doc style in PATCH3
> > - Removed redundant loop in ipi_mux_process() of PATCH3
> > - Removed "RISC-V" prefix form ipi_mux_chip.name of PATCH3
> > - Removed use of "this patch" in PATCH3 commit description
> > - Addressed few other nit comments in PATCH3
> >
> > Changes since v4:
> > - Rebased on Linux-5.17
> > - Includes new PATCH3 which adds mechanism to multiplex a single HW IPI
> >
> > Changes since v3:
> > - Rebased on Linux-5.17-rc6
> > - Updated PATCH2 to not export riscv_set_intc_hwnode_fn()
> > - Simplified riscv_intc_hwnode() in PATCH2
> >
> > Changes since v2:
> > - Rebased on Linux-5.17-rc4
> > - Updated PATCH2 to not create synthetic INTC fwnode and instead provide
> > a function which allows drivers to directly discover INTC fwnode
> >
> > Changes since v1:
> > - Use synthetic fwnode for INTC instead of irq_set_default_host() in PATCH2
> >
> > Anup Patel (8):
> > RISC-V: Clear SIP bit only when using SBI IPI operations
> > irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode
> > genirq: Add mechanism to multiplex a single HW IPI
> > RISC-V: Treat IPIs as normal Linux IRQs
> > RISC-V: Allow marking IPIs as suitable for remote FENCEs
> > RISC-V: Use IPIs for remote TLB flush when possible
> > RISC-V: Use IPIs for remote icache flush when possible
> > irqchip/riscv-intc: Add empty irq_eoi() for chained irq handlers
> >
> > Marc Zyngier (1):
> > irqchip/apple-aic: Move over to core ipi-mux
> >
> > arch/riscv/Kconfig | 2 +
> > arch/riscv/include/asm/irq.h | 4 +
> > arch/riscv/include/asm/sbi.h | 9 +-
> > arch/riscv/include/asm/smp.h | 49 +++++--
> > arch/riscv/kernel/Makefile | 1 +
> > arch/riscv/kernel/cpu-hotplug.c | 3 +-
> > arch/riscv/kernel/irq.c | 21 ++-
> > arch/riscv/kernel/sbi-ipi.c | 77 +++++++++++
> > arch/riscv/kernel/sbi.c | 100 +++------------
> > arch/riscv/kernel/smp.c | 171 ++++++++++++------------
> > arch/riscv/kernel/smpboot.c | 5 +-
> > arch/riscv/mm/cacheflush.c | 5 +-
> > arch/riscv/mm/tlbflush.c | 93 +++++++++++---
> > drivers/clocksource/timer-clint.c | 65 +++++++---
> > drivers/irqchip/Kconfig | 2 +
> > drivers/irqchip/irq-apple-aic.c | 161 ++---------------------
> > drivers/irqchip/irq-riscv-intc.c | 71 ++++++----
> > include/linux/irq.h | 3 +
> > kernel/irq/Kconfig | 5 +
> > kernel/irq/Makefile | 1 +
> > kernel/irq/ipi-mux.c | 207 ++++++++++++++++++++++++++++++
> > 21 files changed, 654 insertions(+), 401 deletions(-)
> > create mode 100644 arch/riscv/kernel/sbi-ipi.c
> > create mode 100644 kernel/irq/ipi-mux.c
> >
> > --
> > 2.34.1
> >
>
> Friendly ping ?
Any further comments on this series ?
Regards,
Anup
On Tue, 03 Jan 2023 14:12:12 +0000,
Anup Patel <[email protected]> wrote:
>
> This series aims to improve IPI support in Linux RISC-V in following ways:
> 1) Treat IPIs as normal per-CPU interrupts instead of having custom RISC-V
> specific hooks. This also makes Linux RISC-V IPI support aligned with
> other architectures.
> 2) Remote TLB flushes and icache flushes should prefer local IPIs instead
> of SBI calls whenever we have specialized hardware (such as RISC-V AIA
> IMSIC and RISC-V SWI) which allows S-mode software to directly inject
> IPIs without any assistance from M-mode runtime firmware.
[...]
I'm queuing patches 3 and 9 via the irqchip tree as they are
standalone.
For the rest, I need an Ack from the riscv maintainers as they change
a large amount of arch-specific code, and the couple of irqchip
patches depend on these changes.
Palmer, Paul?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
The following commit has been merged into the irq/irqchip-next branch of irqchip:
Commit-ID: 835a486cd9f55790dee9f6b67ce0057d49f15da5
Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/835a486cd9f55790dee9f6b67ce0057d49f15da5
Author: Anup Patel <[email protected]>
AuthorDate: Tue, 03 Jan 2023 19:42:15 +05:30
Committer: Marc Zyngier <[email protected]>
CommitterDate: Sun, 05 Feb 2023 10:57:55
genirq: Add mechanism to multiplex a single HW IPI
All RISC-V platforms have a single HW IPI provided by the INTC local
interrupt controller. The HW method to trigger INTC IPI can be through
external irqchip (e.g. RISC-V AIA), through platform specific device
(e.g. SiFive CLINT timer), or through firmware (e.g. SBI IPI call).
To support multiple IPIs on RISC-V, add a generic IPI multiplexing
mechanism which help us create multiple virtual IPIs using a single
HW IPI. This generic IPI multiplexing is inspired by the Apple AIC
irqchip driver and it is shared by various RISC-V irqchip drivers.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Hector Martin <[email protected]>
Tested-by: Hector Martin <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
include/linux/irq.h | 3 +-
kernel/irq/Kconfig | 5 +-
kernel/irq/Makefile | 1 +-
kernel/irq/ipi-mux.c | 207 ++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 216 insertions(+)
create mode 100644 kernel/irq/ipi-mux.c
diff --git a/include/linux/irq.h b/include/linux/irq.h
index c3eb896..b1b28af 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1266,6 +1266,9 @@ int __ipi_send_mask(struct irq_desc *desc, const struct cpumask *dest);
int ipi_send_single(unsigned int virq, unsigned int cpu);
int ipi_send_mask(unsigned int virq, const struct cpumask *dest);
+void ipi_mux_process(void);
+int ipi_mux_create(unsigned int nr_ipi, void (*mux_send)(unsigned int cpu));
+
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
/*
* Registers a generic IRQ handling function as the top-level IRQ handler in
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index b64c44a..2531f34 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -86,6 +86,11 @@ config GENERIC_IRQ_IPI
depends on SMP
select IRQ_DOMAIN_HIERARCHY
+# Generic IRQ IPI Mux support
+config GENERIC_IRQ_IPI_MUX
+ bool
+ depends on SMP
+
# Generic MSI hierarchical interrupt domain support
config GENERIC_MSI_IRQ
bool
diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
index b4f5371..f19d308 100644
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_GENERIC_IRQ_MIGRATION) += cpuhotplug.o
obj-$(CONFIG_PM_SLEEP) += pm.o
obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o
obj-$(CONFIG_GENERIC_IRQ_IPI) += ipi.o
+obj-$(CONFIG_GENERIC_IRQ_IPI_MUX) += ipi-mux.o
obj-$(CONFIG_SMP) += affinity.o
obj-$(CONFIG_GENERIC_IRQ_DEBUGFS) += debugfs.o
obj-$(CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR) += matrix.o
diff --git a/kernel/irq/ipi-mux.c b/kernel/irq/ipi-mux.c
new file mode 100644
index 0000000..3a403c3
--- /dev/null
+++ b/kernel/irq/ipi-mux.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Multiplex several virtual IPIs over a single HW IPI.
+ *
+ * Copyright The Asahi Linux Contributors
+ * Copyright (c) 2022 Ventana Micro Systems Inc.
+ */
+
+#define pr_fmt(fmt) "ipi-mux: " fmt
+#include <linux/cpu.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/jump_label.h>
+#include <linux/percpu.h>
+#include <linux/smp.h>
+
+struct ipi_mux_cpu {
+ atomic_t enable;
+ atomic_t bits;
+};
+
+static struct ipi_mux_cpu __percpu *ipi_mux_pcpu;
+static struct irq_domain *ipi_mux_domain;
+static void (*ipi_mux_send)(unsigned int cpu);
+
+static void ipi_mux_mask(struct irq_data *d)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+
+ atomic_andnot(BIT(irqd_to_hwirq(d)), &icpu->enable);
+}
+
+static void ipi_mux_unmask(struct irq_data *d)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+ u32 ibit = BIT(irqd_to_hwirq(d));
+
+ atomic_or(ibit, &icpu->enable);
+
+ /*
+ * The atomic_or() above must complete before the atomic_read()
+ * below to avoid racing ipi_mux_send_mask().
+ */
+ smp_mb__after_atomic();
+
+ /* If a pending IPI was unmasked, raise a parent IPI immediately. */
+ if (atomic_read(&icpu->bits) & ibit)
+ ipi_mux_send(smp_processor_id());
+}
+
+static void ipi_mux_send_mask(struct irq_data *d, const struct cpumask *mask)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+ u32 ibit = BIT(irqd_to_hwirq(d));
+ unsigned long pending;
+ int cpu;
+
+ for_each_cpu(cpu, mask) {
+ icpu = per_cpu_ptr(ipi_mux_pcpu, cpu);
+
+ /*
+ * This sequence is the mirror of the one in ipi_mux_unmask();
+ * see the comment there. Additionally, release semantics
+ * ensure that the vIPI flag set is ordered after any shared
+ * memory accesses that precede it. This therefore also pairs
+ * with the atomic_fetch_andnot in ipi_mux_process().
+ */
+ pending = atomic_fetch_or_release(ibit, &icpu->bits);
+
+ /*
+ * The atomic_fetch_or_release() above must complete
+ * before the atomic_read() below to avoid racing with
+ * ipi_mux_unmask().
+ */
+ smp_mb__after_atomic();
+
+ /*
+ * The flag writes must complete before the physical IPI is
+ * issued to another CPU. This is implied by the control
+ * dependency on the result of atomic_read() below, which is
+ * itself already ordered after the vIPI flag write.
+ */
+ if (!(pending & ibit) && (atomic_read(&icpu->enable) & ibit))
+ ipi_mux_send(cpu);
+ }
+}
+
+static const struct irq_chip ipi_mux_chip = {
+ .name = "IPI Mux",
+ .irq_mask = ipi_mux_mask,
+ .irq_unmask = ipi_mux_unmask,
+ .ipi_send_mask = ipi_mux_send_mask,
+};
+
+static int ipi_mux_domain_alloc(struct irq_domain *d, unsigned int virq,
+ unsigned int nr_irqs, void *arg)
+{
+ int i;
+
+ for (i = 0; i < nr_irqs; i++) {
+ irq_set_percpu_devid(virq + i);
+ irq_domain_set_info(d, virq + i, i, &ipi_mux_chip, NULL,
+ handle_percpu_devid_irq, NULL, NULL);
+ }
+
+ return 0;
+}
+
+static const struct irq_domain_ops ipi_mux_domain_ops = {
+ .alloc = ipi_mux_domain_alloc,
+ .free = irq_domain_free_irqs_top,
+};
+
+/**
+ * ipi_mux_process - Process multiplexed virtual IPIs
+ */
+void ipi_mux_process(void)
+{
+ struct ipi_mux_cpu *icpu = this_cpu_ptr(ipi_mux_pcpu);
+ irq_hw_number_t hwirq;
+ unsigned long ipis;
+ unsigned int en;
+
+ /*
+ * Reading enable mask does not need to be ordered as long as
+ * this function is called from interrupt handler because only
+ * the CPU itself can change it's own enable mask.
+ */
+ en = atomic_read(&icpu->enable);
+
+ /*
+ * Clear the IPIs we are about to handle. This pairs with the
+ * atomic_fetch_or_release() in ipi_mux_send_mask().
+ */
+ ipis = atomic_fetch_andnot(en, &icpu->bits) & en;
+
+ for_each_set_bit(hwirq, &ipis, BITS_PER_TYPE(int))
+ generic_handle_domain_irq(ipi_mux_domain, hwirq);
+}
+
+/**
+ * ipi_mux_create - Create virtual IPIs multiplexed on top of a single
+ * parent IPI.
+ * @nr_ipi: number of virtual IPIs to create. This should
+ * be <= BITS_PER_TYPE(int)
+ * @mux_send: callback to trigger parent IPI for a particular CPU
+ *
+ * Returns first virq of the newly created virtual IPIs upon success
+ * or <=0 upon failure
+ */
+int ipi_mux_create(unsigned int nr_ipi, void (*mux_send)(unsigned int cpu))
+{
+ struct fwnode_handle *fwnode;
+ struct irq_domain *domain;
+ int rc;
+
+ if (ipi_mux_domain)
+ return -EEXIST;
+
+ if (BITS_PER_TYPE(int) < nr_ipi || !mux_send)
+ return -EINVAL;
+
+ ipi_mux_pcpu = alloc_percpu(typeof(*ipi_mux_pcpu));
+ if (!ipi_mux_pcpu)
+ return -ENOMEM;
+
+ fwnode = irq_domain_alloc_named_fwnode("IPI-Mux");
+ if (!fwnode) {
+ pr_err("unable to create IPI Mux fwnode\n");
+ rc = -ENOMEM;
+ goto fail_free_cpu;
+ }
+
+ domain = irq_domain_create_linear(fwnode, nr_ipi,
+ &ipi_mux_domain_ops, NULL);
+ if (!domain) {
+ pr_err("unable to add IPI Mux domain\n");
+ rc = -ENOMEM;
+ goto fail_free_fwnode;
+ }
+
+ domain->flags |= IRQ_DOMAIN_FLAG_IPI_SINGLE;
+ irq_domain_update_bus_token(domain, DOMAIN_BUS_IPI);
+
+ rc = __irq_domain_alloc_irqs(domain, -1, nr_ipi,
+ NUMA_NO_NODE, NULL, false, NULL);
+ if (rc <= 0) {
+ pr_err("unable to alloc IRQs from IPI Mux domain\n");
+ goto fail_free_domain;
+ }
+
+ ipi_mux_domain = domain;
+ ipi_mux_send = mux_send;
+
+ return rc;
+
+fail_free_domain:
+ irq_domain_remove(domain);
+fail_free_fwnode:
+ irq_domain_free_fwnode(fwnode);
+fail_free_cpu:
+ free_percpu(ipi_mux_pcpu);
+ return rc;
+}
On Sun, 05 Feb 2023 03:04:14 PST (-0800), Marc Zyngier wrote:
> On Tue, 03 Jan 2023 14:12:12 +0000,
> Anup Patel <[email protected]> wrote:
>>
>> This series aims to improve IPI support in Linux RISC-V in following ways:
>> 1) Treat IPIs as normal per-CPU interrupts instead of having custom RISC-V
>> specific hooks. This also makes Linux RISC-V IPI support aligned with
>> other architectures.
>> 2) Remote TLB flushes and icache flushes should prefer local IPIs instead
>> of SBI calls whenever we have specialized hardware (such as RISC-V AIA
>> IMSIC and RISC-V SWI) which allows S-mode software to directly inject
>> IPIs without any assistance from M-mode runtime firmware.
>
> [...]
>
> I'm queuing patches 3 and 9 via the irqchip tree as they are
> standalone.
>
> For the rest, I need an Ack from the riscv maintainers as they change
> a large amount of arch-specific code, and the couple of irqchip
> patches depend on these changes.
>
> Palmer, Paul?
I haven't gotten time to give this a proper review, but I think we've
got enough of a mess with our interrupt handling that it doesn't really
matter so
Acked-by: Palmer Dabbelt <[email protected]>
if you want to take it for this cycle that's fine with me, but I'm also
fine holding off so it can have a while to bake in linux-next -- there's
no real rush for any of this, as there's no hardware yet.
>
> Thanks,
>
> M.
On 2023-02-15 03:17, Palmer Dabbelt wrote:
> On Sun, 05 Feb 2023 03:04:14 PST (-0800), Marc Zyngier wrote:
>> On Tue, 03 Jan 2023 14:12:12 +0000,
>> Anup Patel <[email protected]> wrote:
>>>
>>> This series aims to improve IPI support in Linux RISC-V in following
>>> ways:
>>> 1) Treat IPIs as normal per-CPU interrupts instead of having custom
>>> RISC-V
>>> specific hooks. This also makes Linux RISC-V IPI support aligned
>>> with
>>> other architectures.
>>> 2) Remote TLB flushes and icache flushes should prefer local IPIs
>>> instead
>>> of SBI calls whenever we have specialized hardware (such as
>>> RISC-V AIA
>>> IMSIC and RISC-V SWI) which allows S-mode software to directly
>>> inject
>>> IPIs without any assistance from M-mode runtime firmware.
>>
>> [...]
>>
>> I'm queuing patches 3 and 9 via the irqchip tree as they are
>> standalone.
>>
>> For the rest, I need an Ack from the riscv maintainers as they change
>> a large amount of arch-specific code, and the couple of irqchip
>> patches depend on these changes.
>>
>> Palmer, Paul?
>
> I haven't gotten time to give this a proper review, but I think we've
> got enough of a mess with our interrupt handling that it doesn't
> really matter so
>
> Acked-by: Palmer Dabbelt <[email protected]>
>
> if you want to take it for this cycle that's fine with me, but I'm
> also fine holding off so it can have a while to bake in linux-next --
> there's no real rush for any of this, as there's no hardware yet.
Letting this sort of things simmering in -next is the way.
Now that the basic dependencies are on their way, I'd expect this to be
rebased on 6.3-rc1, and we can then put the whole thing in -next.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
On Mon, Feb 20, 2023 at 2:05 PM Marc Zyngier <[email protected]> wrote:
>
> On 2023-02-15 03:17, Palmer Dabbelt wrote:
> > On Sun, 05 Feb 2023 03:04:14 PST (-0800), Marc Zyngier wrote:
> >> On Tue, 03 Jan 2023 14:12:12 +0000,
> >> Anup Patel <[email protected]> wrote:
> >>>
> >>> This series aims to improve IPI support in Linux RISC-V in following
> >>> ways:
> >>> 1) Treat IPIs as normal per-CPU interrupts instead of having custom
> >>> RISC-V
> >>> specific hooks. This also makes Linux RISC-V IPI support aligned
> >>> with
> >>> other architectures.
> >>> 2) Remote TLB flushes and icache flushes should prefer local IPIs
> >>> instead
> >>> of SBI calls whenever we have specialized hardware (such as
> >>> RISC-V AIA
> >>> IMSIC and RISC-V SWI) which allows S-mode software to directly
> >>> inject
> >>> IPIs without any assistance from M-mode runtime firmware.
> >>
> >> [...]
> >>
> >> I'm queuing patches 3 and 9 via the irqchip tree as they are
> >> standalone.
> >>
> >> For the rest, I need an Ack from the riscv maintainers as they change
> >> a large amount of arch-specific code, and the couple of irqchip
> >> patches depend on these changes.
> >>
> >> Palmer, Paul?
> >
> > I haven't gotten time to give this a proper review, but I think we've
> > got enough of a mess with our interrupt handling that it doesn't
> > really matter so
> >
> > Acked-by: Palmer Dabbelt <[email protected]>
> >
> > if you want to take it for this cycle that's fine with me, but I'm
> > also fine holding off so it can have a while to bake in linux-next --
> > there's no real rush for any of this, as there's no hardware yet.
>
> Letting this sort of things simmering in -next is the way.
>
> Now that the basic dependencies are on their way, I'd expect this to be
> rebased on 6.3-rc1, and we can then put the whole thing in -next.
Okay, I will rebase on 6.3-rc1 whenever it is available.
Thanks,
Anup
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...