| Message ID | 20210311164712.652608-1-anup.patel@wdc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | IPI and remote TBL flush improvement | expand |
On Thu, 11 Mar 2021 08:47:09 PST (-0800), Anup Patel wrote: > This series primarily does two things: > 1. Allows RISC-V IPI provider to specificy whether IPI operations are > suitable for remote TLB flush (PATCH1) > 2. Improve remote TLB flush to use IPIs whenever possible (PATCH2) > 3. Allow irqchip drivers to handle IPIs from chained IRQ handlers (PATCH3) IIUC this last one isn't technically used in both forms, as we don't have any drivers that behave that way yet? I'm OK taking it, under the assumption it makes keeping the out-of-tree driver for the draft interrupt controller easier, but I was wrong then it's probably out of order so I figured I'd check. Aside from that this generally LGTM. We are making quite a bit of mess in here, but I don't really see a way around that as we need to support the old hardware. We can always do a cleanup when the specifications settle down. Oddly enough this did come up in IRC recently and there may be some new bits in the CLINT on the FU740 that allow S-mode SW interrupts to show up directly -- there's at least a "delegate supervisor software interrupt" bit now, but the manual only calls out machine mode as being able to set it (though IIUC it's memory mapped, so not sure how that would be enforced). Not saying we need that in order to take the last patch, but if it is possible it's probably worth giving it a shot when the boards show up. > This series also a preparatory series for upcoming RISC-V advanced > interrupt architecture (AIA) support. > > These patches can be found in riscv_ipi_imp_v1 branch at > https://github.com/avpatel/linux > > Anup Patel (3): > RISC-V: IPI provider should specify if we can use IPI for remote FENCE > RISC-V: Use IPIs for remote TLB flush when possible > RISC-V: Add handle_IPI_noregs() for irqchip drivers > > arch/riscv/include/asm/smp.h | 19 +++++++++- > arch/riscv/kernel/sbi.c | 2 +- > arch/riscv/kernel/smp.c | 30 +++++++++++---- > arch/riscv/mm/cacheflush.c | 2 +- > arch/riscv/mm/tlbflush.c | 62 ++++++++++++++++++++++++------- > drivers/clocksource/timer-clint.c | 2 +- > 6 files changed, 91 insertions(+), 26 deletions(-)
On Wed, Mar 17, 2021 at 10:23 AM Palmer Dabbelt <palmerdabbelt@google.com> wrote: > > On Thu, 11 Mar 2021 08:47:09 PST (-0800), Anup Patel wrote: > > This series primarily does two things: > > 1. Allows RISC-V IPI provider to specificy whether IPI operations are > > suitable for remote TLB flush (PATCH1) > > 2. Improve remote TLB flush to use IPIs whenever possible (PATCH2) > > 3. Allow irqchip drivers to handle IPIs from chained IRQ handlers (PATCH3) > > IIUC this last one isn't technically used in both forms, as we don't have any > drivers that behave that way yet? I'm OK taking it, under the assumption it > makes keeping the out-of-tree driver for the draft interrupt controller easier, > but I was wrong then it's probably out of order so I figured I'd check. The last patch is for RISC-V AIA drivers I am working on. The draft RISC-V AIA specification is available at: http://www.jhauser.us/RISCV/riscv-interrupts-019.pdf > > Aside from that this generally LGTM. We are making quite a bit of mess in > here, but I don't really see a way around that as we need to support the old > hardware. We can always do a cleanup when the specifications settle down. Not all RISC-V platforms will have a mechanism for direct IPI injection from S-mode so to maintain backward compatibility for older platforms (where IPI injection will be always through SBI calls) we have chosen the current approach. The RISC-V AIA spec is trying to solve this in a way which works for both S-mode (or HS-mode) and VS-mode. The current RISC-V AIA plan is to provide IPIs as software injected MSIs between HARTs and this will work fine for Guest/VM as well. > > Oddly enough this did come up in IRC recently and there may be some new bits in > the CLINT on the FU740 that allow S-mode SW interrupts to show up directly -- > there's at least a "delegate supervisor software interrupt" bit now, but the > manual only calls out machine mode as being able to set it (though IIUC it's > memory mapped, so not sure how that would be enforced). Not saying we need > that in order to take the last patch, but if it is possible it's probably worth > giving it a shot when the boards show up. Adding a few bits in CLINT will not be a complete solution because we also need a mechanism where a Guest/VM can directly inject IPIs without SBI calls to the hypervisor. > > > This series also a preparatory series for upcoming RISC-V advanced > > interrupt architecture (AIA) support. > > > > These patches can be found in riscv_ipi_imp_v1 branch at > > https://github.com/avpatel/linux > > > > Anup Patel (3): > > RISC-V: IPI provider should specify if we can use IPI for remote FENCE > > RISC-V: Use IPIs for remote TLB flush when possible > > RISC-V: Add handle_IPI_noregs() for irqchip drivers > > > > arch/riscv/include/asm/smp.h | 19 +++++++++- > > arch/riscv/kernel/sbi.c | 2 +- > > arch/riscv/kernel/smp.c | 30 +++++++++++---- > > arch/riscv/mm/cacheflush.c | 2 +- > > arch/riscv/mm/tlbflush.c | 62 ++++++++++++++++++++++++------- > > drivers/clocksource/timer-clint.c | 2 +- > > 6 files changed, 91 insertions(+), 26 deletions(-) Regards, Anup