Re: [PATCH v2 3/5] x86,fs/resctrl: Move MSR_IA32_L{2,3}_QOS_CFG scope property to x86 resource

[Reinette Chatre]

Hi Chenyu,

On 10/19/26 11:05 PM, Chen Yu wrote:
> On Mon, Oct 19, 2026 at 04:06:35PM -0700, Reinette Chatre wrote:
>> On 10/18/26 10:40 AM, Chen Yu wrote:
>>> On Wed, Oct 07, 2026 at 02:06:45PM -0700, Reinette Chatre wrote:

...

>>>> @@ -140,6 +143,7 @@ struct rdt_hw_resource {
>>>>  	unsigned int		mon_scale;
>>>>  	unsigned int		mbm_width;
>>>>  	bool			cdp_enabled;
>>>> +	bool			qos_cfg_has_cpu_scope;
>>>>  	bool			mbm_cntr_assign_enabled;
>>>>  	bool			sdciae_enabled;
>>>>  };
>>>
>>> It seems that some flags are in resource scope, while others are in the controller's scope,
>>> cache's flags are in the resource scope, MB's flags are in controller's scope, for example "linear".
>>
>> The goal of this change is to move this information into the only (x86) architectural driver where it
>> is relevant.
>>
>> These "flags" are different in a couple of ways:
>> a) qos_cfg_has_cpu_scope is specific to x86 architecture (thus located in struct rdt_hw_resource of
>>    x86 driver, not struct rdt_resource belonging to resctrl fs) - this information is not exposed
>>    to user space nor is it of use to resctrl filesystem. This is just information internal to
>>    architecture whether the x86 MSR has CPU or domain scope to accommodate this difference between
>>    AMD and Intel.
>> b) the MB controller flags like scalar and linear are associated with the controller,
>>    exposed to user space, and managed by resctrl filesystem.
>>
> 
> I see, the hardware-specific attributes/indicators could be in the hardware resource
> scope(and usually they are global settings), while the MB controller's flag is not hardware
> specific, and they are not global settings.
> 
>> To me this qos_cfg_has_cpu_scope flag is closer to the architectural support you are working on
>> that contains within x86 architecture driver the decision whether it should use ACPI or MSR than
>> it is to control flags.
>>
> 
> It seems to be a little different in the control_mode case, currently control_mode is in the
> struct rdt_resource, but its callback resctrl_arch_control_mode_set() is x86 architecture driver
> specific.

Yes, this is different from control mode. I was actually referring to the CMT ERDT enabling
you are working on where the decision whether to use MMIO as discovered via ACPI or MSR is internal
to x86 driver.

...

>>  
>>> Review-by: Chen Yu <yu.c.chen@xxxxxxxxx>
>> Thanks, but I do not think we have the same view of this change. Please let me know if you
>> still feel this patch is ok after this discussion.
>>
> 
> Yes, thanks for the detailed explanation. This patch is OK with me.
Thank you very much.

Reinette