arch/arm64/include/asm/cpufeature.h | 7 +++++++ arch/arm64/include/asm/el2_setup.h | 4 +++- arch/arm64/kernel/cpufeature.c | 15 +++++++++++---- 3 files changed, 21 insertions(+), 5 deletions(-)
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>
---
arch/arm64/include/asm/cpufeature.h | 7 +++++++
arch/arm64/include/asm/el2_setup.h | 4 +++-
arch/arm64/kernel/cpufeature.c | 15 +++++++++++----
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 4de51f8d92cb..a57870fa96db 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -620,6 +620,13 @@ static inline bool id_aa64pfr0_mpam(u64 pfr0)
return val > 0;
}
+static inline bool id_aa64pfr1_mpamfrac(u64 pfr1)
+{
+ u32 val = cpuid_feature_extract_unsigned_field(pfr1, ID_AA64PFR1_EL1_MPAM_frac_SHIFT);
+
+ return val > 0;
+}
+
static inline bool id_aa64pfr1_mte(u64 pfr1)
{
u32 val = cpuid_feature_extract_unsigned_field(pfr1, ID_AA64PFR1_EL1_MTE_SHIFT);
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index cacd20df1786..606cf14e4044 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -501,7 +501,9 @@
#endif
.macro finalise_el2_state
- check_override id_aa64pfr0, ID_AA64PFR0_EL1_MPAM_SHIFT, .Linit_mpam_\@, .Lskip_mpam_\@, x1, x2
+ check_override id_aa64pfr0, ID_AA64PFR0_EL1_MPAM_SHIFT, .Linit_mpam_\@, .Lmpam_minor_\@, x1, x2
+.Lmpam_minor_\@:
+ check_override id_aa64pfr1, ID_AA64PFR1_EL1_MPAM_frac_SHIFT, .Linit_mpam_\@, .Lskip_mpam_\@, x1, x2
.Linit_mpam_\@:
msr_s SYS_MPAM2_EL2, xzr // use the default partition
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c840a93b9ef9..e8fa6f7cf2a2 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1159,6 +1159,14 @@ static __init void detect_system_supports_pseudo_nmi(void)
static inline void detect_system_supports_pseudo_nmi(void) { }
#endif
+static bool detect_ftr_has_mpam(void)
+{
+ u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
+ u64 pfr1 = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1);
+
+ return id_aa64pfr0_mpam(pfr0) || id_aa64pfr1_mpamfrac(pfr1);
+}
+
void __init init_cpu_features(struct cpuinfo_arm64 *info)
{
/* Before we start using the tables, make sure it is sorted */
@@ -1206,7 +1214,7 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
cpacr_restore(cpacr);
}
- if (id_aa64pfr0_mpam(read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1))) {
+ if (detect_ftr_has_mpam()) {
info->reg_mpamidr = read_cpuid(MPAMIDR_EL1);
init_cpu_ftr_reg(SYS_MPAMIDR_EL1, info->reg_mpamidr);
}
@@ -1462,7 +1470,7 @@ void update_cpu_features(int cpu,
cpacr_restore(cpacr);
}
- if (id_aa64pfr0_mpam(read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1))) {
+ if (detect_ftr_has_mpam()) {
info->reg_mpamidr = read_cpuid(MPAMIDR_EL1);
taint |= check_update_ftr_reg(SYS_MPAMIDR_EL1, cpu,
info->reg_mpamidr, boot->reg_mpamidr);
@@ -2473,7 +2481,7 @@ cpucap_panic_on_conflict(const struct arm64_cpu_capabilities *cap)
static bool
test_has_mpam(const struct arm64_cpu_capabilities *entry, int scope)
{
- if (!has_cpuid_feature(entry, scope))
+ if (!detect_ftr_has_mpam())
return false;
/* Check firmware actually enabled MPAM on this cpu. */
@@ -3078,7 +3086,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.capability = ARM64_MPAM,
.matches = test_has_mpam,
.cpu_enable = cpu_enable_mpam,
- ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, MPAM, 1)
},
{
.desc = "Memory Partitioning And Monitoring Virtualisation",
--
2.25.1Hi 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? Thanks, Ben
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. 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. Best regards, Zeng Heng
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. Thanks, Ben
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. 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. Thanks, Ben
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. > > 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
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
© 2016 - 2026 Red Hat, Inc.