linux-kernel - Re: [PATCH] arm64: cpufeature: Add support for the MPAM v0.1 architecture version

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ad158aad-741e-416d-a6dd-58259c0ce940@arm.com>
Date: Wed, 28 Jan 2026 16:29:41 +0000
From: Ben Horgan <ben.horgan@....com>
To: Zeng Heng <zengheng4@...wei.com>, james.morse@....com,
 miko.lenczewski@....com, thuth@...hat.com, mark.rutland@....com,
 yeoreum.yun@....com, robh@...nel.org, james.clark@...aro.org,
 ahmed.genidi@....com, xry111@...111.site, oupton@...nel.org,
 lpieralisi@...nel.org, catalin.marinas@....com, mrigendra.chaubey@...il.com,
 suzuki.poulose@....com, maz@...nel.org, ardb@...nel.org, broonie@...nel.org,
 will@...nel.org, kevin.brodsky@....com, leo.yan@....com,
 anshuman.khandual@....com, yang@...amperecomputing.com, frederic@...nel.org,
 guohanjun@...wei.com, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Kefeng Wang <wangkefeng.wang@...wei.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 leijitang@...wei.com, "Zengtao (B)" <prime.zeng@...ilicon.com>
Subject: Re: [PATCH] arm64: cpufeature: Add support for the MPAM v0.1
 architecture version



On 1/28/26 15:55, Ben Horgan wrote:
> Hi Zeng,
> 
> On 1/28/26 14:37, Ben Horgan wrote:
>> Hi Zeng,
>>
>> On 1/28/26 08:54, Zeng Heng wrote:
>>>
>>>
>>> On 2026/1/27 22:30, Ben Horgan wrote:
>>>> Hi Zeng,
>>>>
>>>> On 1/4/26 13:34, Zeng Heng wrote:
>>>>> According to the MPAM spec [1], the supported architecture versions are
>>>>> v1.0, v1.1 and v0.1. MPAM versions v0.1 and v1.1 are functionally
>>>>> identical, but v0.1 additionally supports the FORCE_NS feature.
>>>>>
>>>>> ID_AA64PR | ID_AA64PR | MPAM Extension | Notes
>>>>> F0_EL1.   | F1_EL1.   | Architecture   |
>>>>> MPAM      | MPAM_frac | version        |
>>>>> ---------------------------------------------------------------------------
>>>>> 0b0000    | 0b0001    | v0.1           | MPAM v0.1 is implemented.
>>>>>            |           |                | MPAM v0.1 is the same as
>>>>> MPAM v1.1
>>>>>            |           |                | with FORCE_NS which is
>>>>>            |           |                | incompatible with MPAM v1.0.
>>>>> ---------------------------------------------------------------------------
>>>>> 0b0001    | 0b0000    | v1.0           | MPAM v1.0 is implemented.
>>>>> ---------------------------------------------------------------------------
>>>>> 0b0001    | 0b0001    | v1.1           | MPAM v1.1 is implemented.
>>>>>            |           |                | MPAM v1.1 includes all
>>>>> features of
>>>>>            |           |                | MPAM v1.0.
>>>>>            |           |                | It must not include FORCE_NS.
>>>>>
>>>>> FORCE_NS is a feature that operates in EL3 mode. Consequently, the
>>>>> current
>>>>> Linux MPAM driver is also compatible with MPAM v0.1. To support v0.1,
>>>>> the
>>>>> existing driver which only checks ID_AA64PFR0_EL1.MPAM for the major
>>>>> version needs to examine ID_AA64PFR1_EL1.MPAM_frac for the minor version
>>>>> as well.
>>>>>
>>>>> [1] https://developer.arm.com/documentation/ddi0598/db/?lang=en
>>>>>
>>>>> Signed-off-by: Zeng Heng <zengheng4@...wei.com>
>>>> So far we've avoided added MPAM 0.1 support as we don't know of any
>>>> machines using it. What's your motivation here? Do you have a machine
>>>> with MPAM 0.1 that runs mainline linux?
>>>>
>>>
>>> Thank you for your questions and for reviewing this proposal.
>>>
>>> Regarding your inquiry about hardware usage and motivation:
>>>
>>> Our KunPeng 920C chip (and numerous legacy SoCs in the same family)
>>> indeed implement MPAM v0.1 extensions. These are widely deployed in
>>> server and embedded equipment. More importantly, the product roadmap for
>>> these platforms explicitly includes migration to mainline Linux kernels
>>> MPAM driver for long-term support, making upstream MPAM v0.1 driver
>>> support is a critical requirement.
>>
>> Thanks for the explanation. It does seem worthwhile to add mpam 0.1
>> support.
>>
>>>
>>> In the other hand, MPAM v0.1 extension version is formally documented in
>>> the ARM MPAM architecture specification (still included in the newest
>>> ARM DDI 0598D.b version). The specification explicitly defines v0.1 as a
>>> valid implementation for earlier hardware. Supporting documented
>>> architectural features is essential for the goal of hardware
>>> compatibility.
>>>
>>> About technical compatibility, the MPAM v0.1 is designed as a
>>> functionally compatible extension with the existing MPAM driver
>>> framework. After having tested this on actual Kunpeng 920C hardware
>>> and other MPAM v1.0 platforms running mainline kernels, this ensures
>>> zero regression risk for v1.0/v1.1 users.
>>>
>>
>> I've tried your patch with a model, FVP_Base_RevC_2xAEMvA, setting mpam
>> 0.1, 1.0 and 1.1 and the mpam driver probes as expected. For 0.1 this
>> required commenting out the versioning check in mpam_devices.c. It would
>> be good if this patch could come together with another updating that check.
> 
> Apologies, I confused myself with MSC MPAM version vs CPU MPAM version.
> The CPU MPAM version is what's relevant here and the mpam_devices.c
> check is just for the MSC. I'll try running this again on the FVP model
> and actually change the correct version.
> 

I've actually tried the mpam cpu versions in the FVP model now, and I
don't see any problems. I don't see any problems in the code either but
I'm not that familiar with the cpufeatures code so this is not a proper
review.

Thanks,

Ben