Re: [RFC PATCH 09/19] x86/resctrl: Add plza_capable in rdt_resource data structure

[Ben Horgan <ben.horgan@arm.com>]

Hi Babu, Reinette,

On 2/11/26 16:54, Reinette Chatre wrote:
> Hi Ben,
> 
> On 2/11/26 7:19 AM, Ben Horgan wrote:
>> Hi Babu,
>>
>> On 1/21/26 21:12, Babu Moger wrote:
>>> Add plza_capable field to the rdt_resource structure to indicate whether
>>> Privilege Level Zero Association (PLZA) is supported for that resource
>>> type.
>>>
>>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>>> ---
>>>  arch/x86/kernel/cpu/resctrl/core.c     | 6 ++++++
>>>  arch/x86/kernel/cpu/resctrl/rdtgroup.c | 5 +++++
>>>  include/linux/resctrl.h                | 3 +++
>>>  3 files changed, 14 insertions(+)
>>>
>>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
>>> index 2de3140dd6d1..e41fe5fa3f30 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>>> @@ -295,6 +295,9 @@ static __init bool __rdt_get_mem_config_amd(struct rdt_resource *r)
>>>  
>>>  	r->alloc_capable = true;
>>>  
>>> +	if (rdt_cpu_has(X86_FEATURE_PLZA))
>>> +		r->plza_capable = true;
>>> +
>>>  	return true;
>>>  }
>>>  
>>> @@ -314,6 +317,9 @@ static void rdt_get_cache_alloc_cfg(int idx, struct rdt_resource *r)
>>>  	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
>>>  		r->cache.arch_has_sparse_bitmasks = ecx.split.noncont;
>>>  	r->alloc_capable = true;
>>> +
>>> +	if (rdt_cpu_has(X86_FEATURE_PLZA))
>>> +		r->plza_capable = true;
>>>  }
>>>  
>>>  static void rdt_get_cdp_config(int level)
>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> index 885026468440..540e1e719d7f 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> @@ -229,6 +229,11 @@ bool resctrl_arch_get_cdp_enabled(enum resctrl_res_level l)
>>>  	return rdt_resources_all[l].cdp_enabled;
>>>  }
>>>  
>>> +bool resctrl_arch_get_plza_capable(enum resctrl_res_level l)
>>> +{
>>> +	return rdt_resources_all[l].r_resctrl.plza_capable;
>>> +}
>>> +
>>>  void resctrl_arch_reset_all_ctrls(struct rdt_resource *r)
>>>  {
>>>  	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
>>> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
>>> index 63d74c0dbb8f..ae252a0e6d92 100644
>>> --- a/include/linux/resctrl.h
>>> +++ b/include/linux/resctrl.h
>>> @@ -319,6 +319,7 @@ struct resctrl_mon {
>>>   * @name:		Name to use in "schemata" file.
>>>   * @schema_fmt:		Which format string and parser is used for this schema.
>>>   * @cdp_capable:	Is the CDP feature available on this resource
>>> + * @plza_capable:	Is Privilege Level Zero Association capable?
>>>   */
>>>  struct rdt_resource {
>>>  	int			rid;
>>> @@ -334,6 +335,7 @@ struct rdt_resource {
>>>  	char			*name;
>>>  	enum resctrl_schema_fmt	schema_fmt;
>>>  	bool			cdp_capable;
>>> +	bool			plza_capable;
>>
>> Why are you making plza a resource property? Certainly for MPAM we'd
>> want this to be global across resources and I see above that you are
>> just checking a cpu property rather then anything per resource.
> 
> I agree. For reference: https://lore.kernel.org/lkml/6fe647ce-2e65-45dd-9c79-d1c2cb0991fe@intel.com/

Ah, didn't mean to duplicate. Glad we agree.

> > One possible concern for MPAM related to this caught my eye. From
> https://lore.kernel.org/lkml/20260203214342.584712-10-ben.horgan@arm.com/ :
> 
> 	If an SMCU is not shared with other cpus then it is implementation
> 	defined whether the configuration from MPAMSM_EL1 is used or that from
> 	the appropriate MPAMy_ELx. As we set the same, PMG_D and PARTID_D,
> 	configuration for MPAM0_EL1, MPAM1_EL1 and MPAMSM_EL1 the resulting
> 	configuration is the same regardless.
> 
> I admit that I am not yet comfortable with the MPAM register usages ... but from
> above it sounds to me as though if resctrl associates different CLOSID/PARTID and
> RMID/PMG with a task to be used at different privilege levels as planned with this
> work then the mapping to MPAM0_EL1 and MPAM1_EL1 may be easy but MPAMSM_EL1 may be
> difficult?

Thanks for bringing this up. The kernel has limited usage of the SMCU.
The SMCU performs matrix and simd instructions for the cpu. In the
kernel these are just used for save/restore of the simd/matrix register
state at context switch and possibly in the future usage could be
extended in a similar way to old style simd, neon, and be guarded by
something like neon_begin(), neon_end(). If we wish to use kernel
specific pmg/partids for those load/stores we can copy the MPAM1_EL1
configuration into MPAMSM_EL1. (Then it doesn't matter if the
configuration from MPAMSM_EL1 or MPAM1_EL1 is used.) This is analogous
to how we copy MPAM1_EL1 to MPAM2_EL2 to provide a configuration for the
kvm nvhe hypervisor.
See:
https://lore.kernel.org/kvmarm/9a8a163e-887a-45fc-aae5-45e564360c8b@arm.com/T/#m23281370dbcdaca98482769de1eae496afadc3b0

> 
> 
> Reinette
> 
> 

Thanks,

Ben