mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zeng Heng <zengheng4@huawei.com>
To: Ben Horgan <ben.horgan@arm.com>, <james.morse@arm.com>,
	<miko.lenczewski@arm.com>, <thuth@redhat.com>,
	<mark.rutland@arm.com>, <yeoreum.yun@arm.com>, <robh@kernel.org>,
	<james.clark@linaro.org>, <ahmed.genidi@arm.com>,
	<xry111@xry111.site>, <oupton@kernel.org>,
	<lpieralisi@kernel.org>, <catalin.marinas@arm.com>,
	<mrigendra.chaubey@gmail.com>, <suzuki.poulose@arm.com>,
	<maz@kernel.org>, <ardb@kernel.org>, <broonie@kernel.org>,
	<will@kernel.org>, <kevin.brodsky@arm.com>, <leo.yan@arm.com>,
	<anshuman.khandual@arm.com>, <yang@os.amperecomputing.com>,
	<frederic@kernel.org>, <guohanjun@huawei.com>,
	Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <leijitang@huawei.com>,
	"Zengtao (B)" <prime.zeng@hisilicon.com>
Subject: Re: [PATCH] arm64: cpufeature: Add support for the MPAM v0.1 architecture version
Date: Mon, 2 Feb 2026 21:13:46 +0800	[thread overview]
Message-ID: <43cd50df-cd95-4840-3d2d-917f8c9ca45e@huawei.com> (raw)
In-Reply-To: <ad158aad-741e-416d-a6dd-58259c0ce940@arm.com>

Hi Ben,

On 2026/1/29 0:29, Ben Horgan wrote:
> 
> 
> 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@huawei.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.

Since all MPAM MSCs on my local 920C platform displays v1.0 or v1.1
architecture versions in the AIDR register, I did not include the
version check modification in mpam_devices.c for the v1 patch. For the
sake of compatibility support integrity, it is necessary to include the
change in the v2 patch soon.

>>
>> 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.
> 

Sincere thanks for your testing feedback and review.


Best Regards,
Zeng Heng

      reply	other threads:[~2026-02-02 13:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-04 13:34 Zeng Heng
2026-01-27 14:30 ` Ben Horgan
2026-01-28  8:54   ` Zeng Heng
2026-01-28 14:37     ` Ben Horgan
2026-01-28 15:55       ` Ben Horgan
2026-01-28 16:29         ` Ben Horgan
2026-02-02 13:13           ` Zeng Heng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43cd50df-cd95-4840-3d2d-917f8c9ca45e@huawei.com \
    --to=zengheng4@huawei.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=ahmed.genidi@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=ben.horgan@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=frederic@kernel.org \
    --cc=guohanjun@huawei.com \
    --cc=james.clark@linaro.org \
    --cc=james.morse@arm.com \
    --cc=kevin.brodsky@arm.com \
    --cc=leijitang@huawei.com \
    --cc=leo.yan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=miko.lenczewski@arm.com \
    --cc=mrigendra.chaubey@gmail.com \
    --cc=oupton@kernel.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=robh@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=thuth@redhat.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=xry111@xry111.site \
    --cc=yang@os.amperecomputing.com \
    --cc=yeoreum.yun@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®