Message-ID: <CAAhSdy1rY-OOgboucJjzMh7_Vh-3G9cDyt8gtRgNNFHBV6O2Eg@mail.gmail.com>
Date:   Wed, 17 Mar 2021 13:59:17 +0530
From:   Anup Patel <anup@...infault.org>
To:     Palmer Dabbelt <palmerdabbelt@...gle.com>
Cc:     Anup Patel <Anup.Patel@....com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Atish Patra <Atish.Patra@....com>,
        Alistair Francis <Alistair.Francis@....com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 0/3] IPI and remote TBL flush improvement

On Wed, Mar 17, 2021 at 10:23 AM Palmer Dabbelt
<palmerdabbelt@...gle.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

Powered by blists - more mailing lists