Re: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept

[Reinette Chatre]

Hi Chenyu,

On 9/20/26 10:13 PM, Chen, Yu C wrote:
> On 9/19/2026 7:11 AM, Reinette Chatre wrote:
>> Hi Chenyu,
>>
>>> On Mon, Aug 10, 2026 at 11:09:31AM -0700, Reinette Chatre wrote:
>>>>
>>>>  From user space view "legacy" is the existing percentage based MB control
>>>> that user space has been using until now. The only way to support this "legacy"
>>>> user interface with region-aware hardware is to use the MSR interface, no?
>>>> User space does not care whether the hardware uses MSR or MMIO, it just uses
>>>> the MB interface.
>>>> That is, as you also say, until it is possible to map legacy control value to
>>>> region-aware control value at which point the MMIO interface can be used and
>>>> user space can continue to use the MB control without interruption.
>>>>
>>>
>>> While looking at the context of control_mode under the info directory, it is
>>> currently used only for the controller to switch between "legacy" and "native".
>>> However, there is also an explicit requirement for the MBM to switch between
>>> "legacy" and "native" TOGETHER with the MBA.
>>>
>>> According to the RDT spec 6.1.3.1 RDT Control Register for CPU Agents,
>>> it discourages mixing legacy MSR for MBM with region aware MBA:
>>> "It is recommended that software use Region Aware MBM when Region Aware
>>> MBA is enabled and vice versa. Mixed mode use (e.g, legacy MSR
>>> interfaces for MBM with Region Aware MBA or vice versa) is not
>>> supported and may lead to inconsistent behavior"
>>>
>>> That is to say, I'm trying to add logic in the code so that, if control_mode
>>> has switched, the corresponding "mode" for MBM will also be adjusted to the
>>> same mode. The code can enable/create both legacy MBM events/sysfs and region-aware
>>> MBM events/sysfs during bootup, and make one of them visible according to control_mode,
>>> similar to what Babu does in PLZA when hiding a file in
>>> https://lore.kernel.org/lkml/f7bcf19ac8113a1e3d9575739c1a6400c455ce6d.1787772750.git.babu.moger@xxxxxxx/
>>>
>>> May I know whether this approach is doable?
>> This sounds reasonable to me. Since so many changes are between current resctrl and those
>> changes it is difficult to envision how clean such change would be. We should aim to
>> avoid sprinkling "if ("region aware") then" checks all over the place.
>>
>> A switch like this will force "region aware" to support the same number of CLOS/RMID
>> as the MSR interface. Is this a concern?
>>
> 
> It seems that taking the weakest link (minimum) across all sources is a pervasive
> convention in resctrl, which can be used to avoid out-of-bounds CLOS/RMID access.

Right. My question is what is expected if a resource supports different number of
CLOSID/RMID depending on the interface used to manage the resource? More specifically,
resctrl can now interact with the MB resource using two interfaces: MSR and ACPI. Each
interface separately enumerates how many CLOSID/RMID it supports. Thus, it seems possible,
that the MB resource may support X CLOSID over MSR interface and Y CLOSID over ACPI
interface.

resctrl exposes the per-resource CLOSID/RMID to user space and today thus needs to
pick whether it exposes the CLOSID/RMID from MSR interface or from ACPI interface and
that will guide how many resctrl will support during the mount. As you state resctrl
uses the minimum. 

If the user has no intention of using the interface that enforces the minimum then there
is no way today for the user to indicate this and thus obtain benefit of all supported
IDs.

Can it be assumed that a system that supports both MSR and ACPI interfaces will enumerate
the same number of CLOSID and RMID on both interfaces?

> If a future platform does not support the CPUID/MSR interfaces, we can only rely on
> the ACPI table to get the max RMID/CLOSID.
ack.

Reinette