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

[Chen, Yu C]

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

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