[v16,0/9] RISC-V IPI Improvements

  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/20211007123632.697666-1-anup.patel@wdc.com/)

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
  

Hi Marc,

On Tue, Jan 3, 2023 at 7:42 PM Anup Patel <apatel@ventanamicro.com> 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/20211007123632.697666-1-anup.patel@wdc.com/)
>
> 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 <apatel@ventanamicro.com> wrote:
>
> Hi Marc,
>
> On Tue, Jan 3, 2023 at 7:42 PM Anup Patel <apatel@ventanamicro.com> 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/20211007123632.697666-1-anup.patel@wdc.com/)
> >
> > 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 <apatel@ventanamicro.com> 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.
  

On Sun, 05 Feb 2023 03:04:14 PST (-0800), Marc Zyngier wrote:
> On Tue, 03 Jan 2023 14:12:12 +0000,
> Anup Patel <apatel@ventanamicro.com> 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 <palmer@rivosinc.com>

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 <apatel@ventanamicro.com> 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 <palmer@rivosinc.com>
> 
> 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.
  

On Mon, Feb 20, 2023 at 2:05 PM Marc Zyngier <maz@kernel.org> 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 <apatel@ventanamicro.com> 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 <palmer@rivosinc.com>
> >
> > 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...