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

["Chen, Yu C" <yu.c.chen@intel.com>]

Hi Reinette,Tony,

On 9/21/2026 11:01 PM, 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@amd.com/
>>>>
>>>> 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?
> 

Yes, per inquiry with the architect team,
"Regarding Region aware/ERDT MAX RMID value: It should match to CPUID 
Global Max.
Our intent moving forward is to support a consistent RMID space across 
all features
within a given domain type."

Besides, as mentioned by Tony, the max RMID/CLOSID exposed by CPUID is 
the global
gating factor regardless of whether the MSR or MMIO interface is used:
[Section 19.18.6 Monitoring Resource RMID Association]
"software must use CPUID to query the maximum RMID supported by the 
processor. If a
value larger than the maximum RMID is written to IA32_PQR_ASSOC.RMID, a 
#GP(0) fault
will be generated."
So this min() can be used as a safeguard to protect against bogus max 
RMID/CLOSID
from the ACPI table.

thanks,
Chenyu

>> 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