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

[Sunil V L]

On Sun, Oct 18, 2026 at 2:26 AM Drew Fustini <fustini at kernel.org> wrote:
>
> 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 at kernel.org> 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 at linux.alibaba.com>
> > > Co-developed-by: Adrien Ricciardi <aricciardi at baylibre.com>
> > > Signed-off-by: Adrien Ricciardi <aricciardi at baylibre.com>
> > > Signed-off-by: Drew Fustini <fustini at kernel.org>
> > > ---
> > >  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.
>
Sure. Thanks for the explanation.

Thanks,
Sunil