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

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Drew,

On 11/10/26 3:17 PM, Drew Fustini wrote:
> On Sun, Nov 08, 2026 at 03:20:51PM -0800, Drew Fustini wrote:
>> Wire CBQRI capacity controllers into resctrl as the L2 and L3 cache
>> resources.
>>
>> 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, or whose domain cannot be created,
>> still comes online. It is left out of that level and a warning is
>> logged, since bringing the CPU up matters more than controlling its
>> cache traffic. 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.
>>
>> Tested-by: Chen Pei <cp0613@linux.alibaba.com>
>> Acked-by: Reinette Chatre <reinette.chatre@intel.com>
> 
> Hi Reinette, I still need to get more reviews on this series, but I
> wanted to check if your expectation is that all the patches in this
> series should be merged through arch/riscv?
Here I'll defer to what works best for the architecture and tip maintainers.

We still need to create a strategy with the respective architecture maintainers 
for how conflicts between the resctrl filesystem and architecture drivers should
to be resolved. Without encountering this yet this may end up evolving based on
the conflicts encountered. Even so, I think it is worthwhile to at least start the
conversation with the architecture maintainers to introduce that this driver
may need extra support/coordination during merge window.

Reinette