[PATCH v4 00/41] arm_mpam: Add KVM/arm64 and resctrl glue code

[Zeng Heng]

On 2026/2/25 1:53, Ben Horgan wrote:
> Hi Zeng,
> 
>>>
>>> Resctrl mounting status:
>>>
>>> # cat schemata
>>> L2:4=ff;7=ff;10=ff;13=ff;16=ff;19=ff;22=ff;25=ff;29=ff;32=ff;35=ff;
>>> 38=ff;41=ff;44=ff;47=ff;50=ff;54=ff;57=ff;60=ff;63=ff;66=ff;69=ff;72=ff;
>>> 75=ff;79=ff;82=ff;85=ff;88=ff;91=ff;94=ff;97=ff;100=ff;104=ff;107=ff;
>>> 110=ff;113=ff;116=ff;119=ff;122=ff;125=ff;129=ff;132=ff;135=ff;138=ff;
>>> 141=ff;144=ff;147=ff;150=ff;154=ff;157=ff;160=ff;163=ff;166=ff;169=ff;
>>> 172=ff;175=ff;179=ff;182=ff;185=ff;188=ff;191=ff;194=ff;197=ff;200=ff;
>>> 204=ff;207=ff;210=ff;213=ff;216=ff;219=ff;222=ff;225=ff;229=ff;232=ff;
>>> 235=ff;238=ff;241=ff;244=ff;247=ff;250=ff;254=ff;257=ff;260=ff;263=ff;
>>> 266=ff;269=ff;272=ff;275=ff;279=ff;282=ff;285=ff;288=ff;291=ff;294=ff;
>>> 297=ff;300=ff
>>> L3:1=1ffff;26=1ffff;51=1ffff;76=1ffff;101=1ffff;126=1ffff;151=1ffff;
>>> 176=1ffff;201=1ffff;226=1ffff;251=1ffff;276=1ffff
>>>
>>> # ls mon_data/*/*
>>> mon_data/mon_L3_01/llc_occupancy   mon_data/mon_L3_151/llc_occupancy
>>> mon_data/mon_L3_226/llc_occupancy  mon_data/mon_L3_276/llc_occupancy
>>> mon_data/mon_L3_101/llc_occupancy  mon_data/mon_L3_176/llc_occupancy
>>> mon_data/mon_L3_251/llc_occupancy  mon_data/mon_L3_51/llc_occupancy
>>> mon_data/mon_L3_126/llc_occupancy  mon_data/mon_L3_201/llc_occupancy
>>> mon_data/mon_L3_26/llc_occupancy   mon_data/mon_L3_76/llc_occupancy
>>
>> Thanks for the extra details. These are as expected, right?

Yes, Both the resctrl mount functionality and the control domain count
are as expected.

>>
>>>
>>>>>
>>>>> Boot logs:
>>>>> [root at localhost ~]# dmesg | grep -i mpam
>>>>> [    0.000000] ACPI: MPAM 0x000000007FF35018 003024 (v01 HISI   HIP12
>>>>> 00000000 HISI 20151124)
>>>>> [    9.509852] mpam_msc mpam_msc.64: Merging features for
>>>>> vmsc:0xffff0800973cf5a0 |= ris:0xffff08009757ee90
>>>>> [    9.509859] mpam_msc mpam_msc.254: Merging features for
>>>>> class:0xffff08009736fe50 &= vmsc:0xffff080097628520
>>>>> [    9.509860] mpam:__props_mismatch:
>>>>> mpam_has_feature(mpam_feat_cpor_part, parent) = 1
>>>>> [    9.509864] mpam:__props_mismatch:
>>>>> mpam_has_feature(mpam_feat_cpor_part, child) = 0
>>>>> [    9.509866] mpam:__props_mismatch: parent->cpbm_wd = 8
>>>>> [    9.509869] mpam:__props_mismatch: child->cpbm_wd = 0
>>>>> [    9.509871] mpam:__props_mismatch: alias = 0
>>>>> [    9.509873] mpam:__props_mismatch: cleared cpor_part
>>
>> Do you know where this mismatch is happening? Is it expected?

I've rerun tests against the latest v5 and no longer see the
"__props_mismatch" messages. I'll post the newest boot log on the v5
thread soon.

My suspicion is that the MSC initialization refactoring in the MPAM 
driver between v3 and v5 inadvertently fixed the L2 initialization error
printing.

> 
> I have added some of James' debug patches at:
> https://gitlab.arm.com/linux-arm/linux-bh/-/tree/mpam_resctrl_glue_v5_debugfs?ref_type=heads
> 
> These are on top of a v5 of the series. They apply to older series
> as well.
> 
> The debugfs should then contain details of all the MSC which
> should help debugging.
> 
> It would be great if you were able to share that information, either on list or
> privately if needed.
> 
> You can snapshot the mpam debugfs using:
> 
> find /sys/kernel/debug/mpam -type f -exec sh -c 'echo {}; cat {}' \; > mpam_debugfs.txt

I've enabled MPAM debugfs locally on v5 and dumped the logs. The file is
over 100k, which would trigger corporate email security scans if sent
externally.

I've reviewed it briefly and the contents look as expected.


Best regards,
Zeng Heng