From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 829D728C2BF for ; Wed, 28 Jan 2026 16:29:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769617790; cv=none; b=g2R71gUTzPAMwBOVVgweukAZ61TdARYJJ4ST3O88cgIDs55cwZmglpUWZP6e2B7McPYSWOjHHO0ZTE2UAea58KPq92wPBzzpKUxutBQjX/uQWElY1JiMk/7+l3jRQ/h9hsI55X28NkgJGLQ0hrNhXkbhulWm1haWDvyDs+JpTL8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769617790; c=relaxed/simple; bh=xqLA6HNLFx87T2E1McY2YS/1r6mT6wtmvN3k1Fv0eys=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=JRvuVifabuworjq9r8R8l4HkXxVCywLCaOwQkhXVcrUaWPjk+ytMhCzC38GdPsLNByrfNCH7OS4HtyFHiY8+5mEMqIQJJG4Uo/csk+upl7s3Y922qe3nG20aj5PI0uitGUnQ8F0NOY6S1K2LvtpyZChdDjleDi0ErD8in2hSmAQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 647881516; Wed, 28 Jan 2026 08:29:41 -0800 (PST) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 345893F5CA; Wed, 28 Jan 2026 08:29:43 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 16:29:41 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64: cpufeature: Add support for the MPAM v0.1 architecture version From: Ben Horgan To: Zeng Heng , 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 , Kefeng Wang Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, leijitang@huawei.com, "Zengtao (B)" References: <20260104133434.1887677-1-zengheng4@huawei.com> <37f87d5d-bd70-4b13-93e0-8024108be948@arm.com> <0944256a-bcc6-56fa-e3f9-eb3a83c45505@huawei.com> <9006b698-6fb6-4dc0-a7c6-de3fb27fb073@arm.com> <9dbb9767-f616-4f62-996a-08ee8d580521@arm.com> Content-Language: en-US In-Reply-To: <9dbb9767-f616-4f62-996a-08ee8d580521@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 >>>> 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