Re: [External] Re: [PATCH v4 0/6] riscv: implement Ssqosid extension and CBQRI controllers

[Drew Fustini <fustini@kernel.org>]

On Thu, Jan 08, 2026 at 04:46:10PM +0800, yunhui cui wrote:
> Hi Drew,
> 
> On Thu, Jan 8, 2026 at 3:33 PM Drew Fustini <fustini@kernel.org> wrote:
> >
> > On Wed, Jan 07, 2026 at 03:38:34PM +0800, yunhui cui wrote:
> > > Hi Drew,
> > >
> > > On Tue, Jan 6, 2026 at 5:55 AM Drew Fustini <fustini@kernel.org> wrote:
> > > >
> > > > This series implements the RISC-V Quality-of-Service Identifiers
> > > > (Ssqosid) extension [1] which adds the srmcfg register. It also
> > > > implements the RISC-V Capacity and Bandwidth Controller QoS Register
> > > > Interface (CBQRI) specification [2]. Quality of Service (QoS) in this
> > > > context is concerned with shared resources on an SoC such as cache
> > > > capacity and memory bandwidth.
> > > >
> > > > Sssqosid srmcfg CSR
> > > > -------------------
> > > > The srmcfg CSR configures a hart with two identifiers:
> > > >
> > > >  - Resource Control ID (RCID)
> > > >  - Monitoring Counter ID (MCID)
> > > >
> > > > These identifiers accompany each request issued by the hart to shared
> > > > resource controllers. This allows the capacity and bandwidth resources
> > > > used by a software workload (e.g. a process or a set of processes) to be
> > > > controlled and monitored.
> > >
> > > 1. The CBQRI specification does not mandate 64-byte access width for
> > > its registers. Therefore, is it necessary to add a field in the ACPI
> > > RQSC table?
> >
> > Sorry, I don't follow. Why would a new field be needed in RQSC?
> 
> Different manufacturers may design CBQRI registers with different
> widths (32-bit or 64-bit). See:
> https://github.com/riscv-non-isa/riscv-rqsc/issues/10

Thanks for the link. I now understand that you are talking about a field 
to indicate the supported access width. I think Radim's comments
illustrate that software should not have to worry about about 32-bit or
64-bit accesses as the CBQRI spec requires a controller to support both.
I think we will have to wait and see if there are any real hardware
implementations where that is not the case.

> > > 2. In addition, although CBQRI does not require configuring a specific
> > > number of RMIDs for each CLOSID like MPAM does, creating a control
> > > group will by default create a monitoring group. So on RISC-V, the
> > > number of MCIDs should be at least no less than that of RCIDs, right?
> >
> > Yes, I have working on the assumption that the number of MCIDs (RMIDs)
> > will be greater than, or equal to, the number of RCIDs (e.g. CLOSIDs).
> >
> > Chapter 6 of the CBQRI spec states that: "In a typical implementation,
> > the number of RCID bits implemented (for example, to support 10s of
> > RCIDs) might be smaller than the number of MCID bits implemented (for
> > example, to support 100s of MCIDs)."
> >
> > I would be very interested if anyone can share the RCID and MCID count
> > for their CBQRI hardware implementation.
> >
> > > 3. By the way, for Linux, could you also release a version of the
> > > CBQRI/Ssqosid patchset with ACPI support?
> >
> > The series I am about to post for Ssqosid+CBQRI [1] just contains a
> > device tree example, but I will do a followup series for RQSC. The
> > kernel branch [2] from the RQSC proof-of-concept was based on v6.14 so I
> > need to rebase it. The good thing is that 6.19 now has the PPTT helpers
> > from the MPAM driver series.
> 
> Oh, that's great! When will the RQSC-supported patchset based on 6.19
> likely be posted? Looking forward to your update.

I don't think the kernel patches for RQSC will be that complicated to
rebase. However, I think the Qemu branch [1] will take more work as it
was based on an old PPTT patch series [2]. I think I will have the
Ssqosid+CBQRI kernel patch series ready to post tomorrow, so I think it
is reasonable to target posting the rebased RQSC series for Linux and
Qemu 1 week later.

Thanks,
Drew

[1] https://github.com/tt-fustini/qemu/commits/riscv-cbqri-rqsc-pptt/
[2] https://lore.kernel.org/all/20240129104039.117671-1-jeeheng.sia@starfivetech.com/`