Re: [PATCH v11 0/9] riscv: add SBI Supervisor Software Events support
From: Anup Patel
Date: Thu Oct 29 2026 - 02:03:05 EST
On Thu, Oct 29, 2026 at 9:10 AM Zhanpeng Zhang
<zhangzhanpeng.jasper@xxxxxxxxxxxxx> wrote:
>
> Hi all,
>
> On 10/29/26 11:17 AM, Anup Patel wrote:
> > On Thu, Oct 29, 2026 at 8:36 AM Zhanpeng Zhang
> > <zhangzhanpeng.jasper@xxxxxxxxxxxxx> wrote:
> >>
> >> Hi Anup, Paul, Himanshu,
> >>
> >> On 10/29/26 12:55 AM, Anup Patel wrote:
> >>
> >>> [...]
> >>>
> >>> Changes in v11
> >>> ==============
> >>>
> >>> Rebased on latest for-next branch of linux-riscv tree (commit a5ae1bf65cee).
> >>> Also, tested PMU driver with both PMU irqs and PMU SSE events.
> >>>
> >>
> >> Thanks for rebasing and testing the series. I was a little surprised
> >> to see v11 posted, as I am still working through Himanshu's v10 review
> >> and validating the fixes on hardware. It would have been helpful to
> >> coordinate before reposting so that those changes could be included.
> >>
> >> I guess this follows Paul's request to rebase onto riscv/for-next.
> >> However, there is one change beyond the rebase that I would like to
> >> clarify: why does patch 4 remove the scoped_guard(preempt) sections
> >> from the CPU hotplug paths? These were present in v10 RESEND, and
> >> the local helpers still retain their preemption-disabled assertions.
> >> Is there a reason this protection is no longer needed?
> >
> > Yes, this is based on discussion with Paul yesterday.
> >
> > This series is blocking the whole RAS ACPI support.
> >
> >>
> >> The changes discussed on the v10 threads are still outstanding in
> >> this posting:
> >>
> >> - Preserve TASK_TI_A0/A1/A2 across nested exceptions.
> >> - Replace the temporary GUP-based perf user-stack copy with nofault
> >> uaccess, following the x86 approach.
> >> - Address the per-CPU initialization/preemption concern.
> >> - Split the MAINTAINERS updates into a separate patch.
> >
> > There is always going to be new updates since it will take
> > time to harden the SSE implementation. All these changes
> > can be done as separate follow-on patches.
> >
> >>
> >> Additional fixes from Sashiko review, the kernel test robot report,
> >> and our follow-up debugging are also being consolidated:
> >>
> >> - NMI-safe entry and lockdep irqflags tracking.
> >> - The unused-function warning reported by the kernel test robot.
> >> - RV32 vmalloc synchronization before nofault fixup.
> >> - Faulting-PC validation in the kprobe single-step fault path.
> >> - Per-counter STOP handling in SSE error paths.
> >> - Ordinary IRQ CPU-PM notifier ordering and IRQ cleanup tracking.
> >
> > Same comment as above, please do this as separate series.
> > No point in holding all other dependent work endlessly.
> >
>
> I agree that we should unblock the dependent work. However, I would
> not characterize addressing a known, reproduced issue as holding things
> up endlessly.
>
> >>
> >> In particular, Himanshu identified the missing preservation of
> >> TASK_TI_A0/A1/A2 across nested exceptions [1]. Following his review,
> >> I validated the fix with hardware A/B testing: removing it reproduced
> >> corruption, while the fixed kernel completed the same test sequence.
> >> This also gives us a solid basis for replacing the temporary GUP
> >> workaround with nofault uaccess.
> >>
> >> Paul, please hold off on taking this version into for-next until
> >> these fixes are included. The rebase and PMU testing are useful, but
> >> there are still outstanding correctness issues.
> >>
> >> I will consolidate the changes and post v12 against riscv/for-next,
> >> with an updated changelog and validation results. Let's coordinate
> >> the next posting to keep everything together.
> >>
> >> Thanks,
> >> Zhanpeng
> >>
> >> [1] https://lore.kernel.org/r/as79MHtNYd-VbUug@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >
> > Regards,
> > Anup
>
> I'll post a focused v12 before this weekend with the immediate
> correctness fixes. Further improvements can follow separately.
Linux-7.4 merge window closes end-of this week so your v12
will be too late for it hence I suggest sending incremental fixes
separately.
Regards,
Anup