Re: [PATCH v9 2/5] riscv_cbqri: resctrl: Add cache allocation via capacity block mask

[Drew Fustini]

On Mon, Oct 12, 2026 at 10:23:57PM +0530, Sunil V L wrote:
> On Sat, Oct 3, 2026 at 12:45 PM Drew Fustini <fustini@xxxxxxxxxx> wrote:
> >
> > Wire CBQRI capacity controllers into resctrl as RDT_RESOURCE_L2 and
> > RDT_RESOURCE_L3 schemata.
> >
> > resctrl exposes a single capacity mask per resource, so when more than
> > one capacity controller backs a cache level they must report the same
> > number of capacity blocks. The same holds for the other capabilities
> > resctrl exposes once per resource. A level whose controllers disagree
> > is left unexposed. Other levels are unaffected.
> >
> > The set of controllers backing each level is fixed when resctrl is set
> > up at late_initcall. Control domains are created in the cpuhp online
> > callback and keyed on the onlining CPU's cache id from cacheinfo, so a
> > CPU that is offline at probe time still joins its domain once it comes
> > online, provided a controller for its cache is in that set. A CPU whose
> > cache has no controller is left out of that level and a warning is
> > logged once. A domain is published on the ctrl_domains RCU list only
> > after it is fully initialized and brought online, and removed from the
> > list before it is taken offline, following the documented safe
> > traversal rules.
> >
> > Assisted-by: LLM
> > Tested-by: Chen Pei <cp0613@xxxxxxxxxxxxxxxxx>
> > Co-developed-by: Adrien Ricciardi <aricciardi@xxxxxxxxxxxx>
> > Signed-off-by: Adrien Ricciardi <aricciardi@xxxxxxxxxxxx>
> > Signed-off-by: Drew Fustini <fustini@xxxxxxxxxx>
> > ---
> >  MAINTAINERS                      |   2 +
> >  arch/riscv/include/asm/resctrl.h | 147 +++++++
> >  drivers/resctrl/Kconfig          |   4 +
> >  drivers/resctrl/Makefile         |   1 +
> >  drivers/resctrl/cbqri_resctrl.c  | 831 +++++++++++++++++++++++++++++++++++++++
> >  5 files changed, 985 insertions(+)
[..]
> > diff --git a/drivers/resctrl/cbqri_resctrl.c b/drivers/resctrl/cbqri_resctrl.c
> > new file mode 100644
> > index 000000000000..f10a24761b25
> > --- /dev/null
> > +++ b/drivers/resctrl/cbqri_resctrl.c
[..]
> > +static int cbqri_resctrl_setup(void)
> > +{
> > +       int rid;
> > +       int err;
> > +
> > +       for (rid = 0; rid < RDT_NUM_RESOURCES; rid++)
> > +               cbqri_resctrl_resources[rid].resctrl_res.rid = rid;
> > +
> Why can't cbqri_resctrl_control_init directly use
> cbqri_resctrl_resources? I feel this initialization is redundant.

This is similar to what x86 and arm mpam also do since it is important
before any resctrl code is called. for_each_rdt_resource() will get
stuck in a loop if the rid values are not initialized. In contrast,
cbqri_resctrl_control_init() only handles the resources for which
cbqri_resctrl_pick_caches() found a controller.

The initialization could be moved into cbqri_resctrl_control_init()
before any early return paths but it does introduce the possibility that
rid initialization could be missed if cbqri_resctrl_control_init() is
ever refactored. Given that, I'm inclined to keep the current structure.

Thanks,
Drew