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

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

Hi Chenyu,

On 8/10/26 10:23 AM, Chen, Yu C wrote:
> Hi Reinette,
> 
> On 8/10/2026 11:53 PM, Reinette Chatre wrote:
> 
> [ ... ]
> 
>>> item 1.
>>> In legacy mode, we intend to always let the "native" controller
>>> emulate the "legacy" controller - at least for the region‑aware
>>> RDT case.
>>> Q1: Is this understanding correct?
>>
>> As I understand region-aware is what actually makes this impossible to do
>> since there is no mapping from "legacy" percentage based control value to
>> "native" control value. Even more, the hardware self has two separate interfaces:
>> "legacy" uses MSR interface and "native" uses ACPI interface. As I see it a
>> region aware system in "legacy" mode is using the "legacy" MSR interface and
>> not use the "native" ACPI interface *at all*.
>>   
> 
> OK. Previously I might have misunderstood what "legacy" means in this context:
> "legacy control means using the existing MB interface in the schemata to
> change the percentage value. That is to say, no matter whether
> the underlying mechanism is based on MSR or MMIO, it is transparent to the
> resctrl user."
> which was discussed here:https://lore.kernel.org/lkml/87e4ca90-01bb-47e9-8892-0d2d56468bc0@intel.com/

Right ... but if the existing MB user space interface can only be supported by
MSR then it becomes the only "underlying mechanism". 

> I think "legacy" now refers to "MSR" in the context of region-aware RDT,
> due to lack of mapping between MSR-based and MMIO-based values.

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.


>>> item 2.
>>> In commit fbed64f80515 ("x86/resctrl: SAMPLE: Emulated controls"),
>>> during resctrl initialization, __get_mem_config_intel() clears
>>> the legacy controller's hw_ctrl->msr_update to NULL, and sets
>>> its emulation controllers in hw_ctrl->r_ctrl.emulated_by to
>>> the region-aware related controllers. So legacy controller is
>>> emulated by region-aware controllers.
>>>
>>> item 3.
>>> In resctrl_arch_control_mode_set(), when switching to "legacy"
>>> mode, the legacy controller is set to:
>>> hw_ctrl->msr_update = update_temporary_legacy_MB;
>>> while the emulating controller is set to NULL:
>>> hw_ctrl->msr_update = NULL;
>>> That means, the emulated controllers will not take effect.
>>>
>>> Q2:Does item 3 contradict item 1?
>> The switching of .msr_update() is sample code to present a PoC of how
>> region-aware could be supported based on my understanding described above.
>> I expected that, for example, when user space switches the control mode between
>> "legacy"/"native" then the region-aware code would disable/enable region-aware
>> mode via the RDT_CTRL register and adjust the .msr_update() to match what
>> hardware interface is active.
>>
>> If at some point in future it becomes possible for resctrl to know how to
>> map a legacy control value to a native control value for region aware then this
>> switching should no longer be necessary and the "native" fine grained controller
>> can always be used to emulate the "legacy" percentage based controller and to
>> support this the ACPI interface would be enabled all the time.
>>
> 
> Then for the current region-aware MBA, should we add region-aware controllers
> as the same level as legacy controller, instead of adding them in legacy
> controllers' emulated_by list, since the legacy controller is not
> emulated by region-aware controllers? And we might need to introduce enable/disable
> flag per controller, which could be switched on/off when switching between
> legacy and native.
Please consider what will be required to support per-controller dynamic ("enable" vs "disable")
state: resctrl fs needs to expose interfaces that accept control changes from user space after
initialization that needs to be supported by architecture. In the current design resctrl fs expects
controllers to be set and configured at the time it starts so such change would require new locking
between resctrl fs and architecture. This complexity does not seem necessary to me since switching
between legacy and native accomplishes the same, no?

I find "region-aware controllers at the same level as legacy controller" together with
"per controller enable/disable" conflicting since it creates impression that user space can
enable/disable the controllers independently while there is a required dependency among the
different controllers based on whether hardware has region-aware MBA enabled or not. Even
here there would be a requirement to communicate to userspace which controllers could be
enabled/disabled together ... which is the same as the emulated list, no?

Also consider the future:
(a) Would it be possible to map legacy control value to region aware control value in the future?
    I believe the answer is "yes". If resctrl starts by displaying the region-aware controllers
    as emulating the legacy controller in info/ then the transition to support this will
    be smooth.

(b) Would MSR interface always be available? 
    I do not think resctrl should always assume this to be the case. Here I also find that starting
    with exposing region aware controllers as emulating the legacy controller in info/ to support
    a smooth transition.

What problem(s) do you envision? 

Reinette