Hi all,

Just a handful of minor changes based on v5 review comments. See individual
patches for change lgos. I haven't asked James to host any branches for this
revision but please let me know if this would be helpful to anyone. Thanks for
all the help with reviews and testing.

Previous cover letter from James:

This is just enough MPAM driver for ACPI. DT got ripped out. If you need DT
support - please share your DTS so the DT folk know the binding is what is
needed.
This doesn't contain any of the resctrl code, meaning you can't actually drive it
from user-space yet. Because of that, its hidden behind CONFIG_EXPERT.
This will change once the user interface is connected up.

This is the initial group of patches that allows the resctrl code to be built
on top. Including that will increase the number of trees that may need to
coordinate, so breaking it up make sense.

The locking got simplified, but is still strange - this is because of the 'mpam-fb'
firmware interface specification that is still alpha. That thing needs to wait for
an interrupt after every system register write, which significantly impacts the
driver. Some features just won't work, e.g. reading the monitor registers via
perf.

I've not found a platform that can test all the behaviours around the monitors,
so this is where I'd expect the most bugs.

The MPAM spec that describes all the system and MMIO registers can be found here:
https://developer.arm.com/documentation/ddi0598/db/?lang=en
(Ignored the 'RETIRED' warning - that is just arm moving the documentation around.
 This document has the best overview)

The expectation is this will go via the arm64 tree.

This series is based on v6.18-rc4, and can be retrieved from: (no v6 version)
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/driver/v5

The rest of the driver can be found here: (no v6 version)
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/snapshot/v6.18-rc4-v5

What is MPAM? Set your time-machine to 2020:
https://lore.kernel.org/lkml/20201030161120.227225-1-james.morse@arm.com/

Ben Horgan (5):
  ACPI / PPTT: Add acpi_pptt_cache_v1_full to use pptt cache as one
    structure
  platform: Define platform_device_put cleanup handler
  ACPI: Define acpi_put_table cleanup handler and
    acpi_get_table_pointer() helper
  arm_mpam: Consider overflow in bandwidth counter state
  MAINTAINERS: new entry for MPAM Driver

James Morse (27):
  ACPI / PPTT: Add a helper to fill a cpumask from a processor container
  ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear
    levels
  ACPI / PPTT: Find cache level by cache-id
  ACPI / PPTT: Add a helper to fill a cpumask from a cache_id
  arm64: kconfig: Add Kconfig entry for MPAM
  ACPI / MPAM: Parse the MPAM table
  arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate
  arm_mpam: Add the class and component structures for firmware
    described ris
  arm_mpam: Add MPAM MSC register layout definitions
  arm_mpam: Add cpuhp callbacks to probe MSC hardware
  arm_mpam: Probe hardware to find the supported partid/pmg values
  arm_mpam: Add helpers for managing the locking around the mon_sel
    registers
  arm_mpam: Probe the hardware features resctrl supports
  arm_mpam: Merge supported features during mpam_enable() into
    mpam_class
  arm_mpam: Reset MSC controls from cpuhp callbacks
  arm_mpam: Add a helper to touch an MSC from any CPU
  arm_mpam: Extend reset logic to allow devices to be reset any time
  arm_mpam: Register and enable IRQs
  arm_mpam: Use a static key to indicate when mpam is enabled
  arm_mpam: Allow configuration to be applied and restored during cpu
    online
  arm_mpam: Probe and reset the rest of the features
  arm_mpam: Add helpers to allocate monitors
  arm_mpam: Add mpam_msmon_read() to read monitor value
  arm_mpam: Track bandwidth counter state for power management
  arm_mpam: Add helper to reset saved mbwu state
  arm_mpam: Add kunit test for bitmap reset
  arm_mpam: Add kunit tests for props_mismatch()

Rohit Mathew (2):
  arm_mpam: Probe for long/lwd mbwu counters
  arm_mpam: Use long MBWU counters if supported

 MAINTAINERS                         |   10 +
 arch/arm64/Kconfig                  |   25 +
 drivers/Kconfig                     |    2 +
 drivers/Makefile                    |    1 +
 drivers/acpi/arm64/Kconfig          |    3 +
 drivers/acpi/arm64/Makefile         |    1 +
 drivers/acpi/arm64/mpam.c           |  411 ++++
 drivers/acpi/pptt.c                 |  280 ++-
 drivers/acpi/tables.c               |    2 +-
 drivers/resctrl/Kconfig             |   24 +
 drivers/resctrl/Makefile            |    4 +
 drivers/resctrl/mpam_devices.c      | 2723 +++++++++++++++++++++++++++
 drivers/resctrl/mpam_internal.h     |  658 +++++++
 drivers/resctrl/test_mpam_devices.c |  389 ++++
 include/linux/acpi.h                |   26 +
 include/linux/arm_mpam.h            |   66 +
 include/linux/platform_device.h     |    1 +
 17 files changed, 4608 insertions(+), 18 deletions(-)
 create mode 100644 drivers/acpi/arm64/mpam.c
 create mode 100644 drivers/resctrl/Kconfig
 create mode 100644 drivers/resctrl/Makefile
 create mode 100644 drivers/resctrl/mpam_devices.c
 create mode 100644 drivers/resctrl/mpam_internal.h
 create mode 100644 drivers/resctrl/test_mpam_devices.c
 create mode 100644 include/linux/arm_mpam.h

-- 
2.43.0

Hi Ben, James

Ben Horgan <ben.horgan@arm.com> writes:

> Hi all,
>
> Just a handful of minor changes based on v5 review comments. See individual
> patches for change lgos. I haven't asked James to host any branches for this
> revision but please let me know if this would be helpful to anyone. Thanks for
> all the help with reviews and testing.
>
> Previous cover letter from James:
>
> This is just enough MPAM driver for ACPI. DT got ripped out. If you need DT
> support - please share your DTS so the DT folk know the binding is what is
> needed.
> This doesn't contain any of the resctrl code, meaning you can't actually drive it
> from user-space yet. Because of that, its hidden behind CONFIG_EXPERT.
> This will change once the user interface is connected up.
>
> This is the initial group of patches that allows the resctrl code to be built
> on top. Including that will increase the number of trees that may need to
> coordinate, so breaking it up make sense.
>
> The locking got simplified, but is still strange - this is because of the 'mpam-fb'
> firmware interface specification that is still alpha. That thing needs to wait for
> an interrupt after every system register write, which significantly impacts the
> driver. Some features just won't work, e.g. reading the monitor registers via
> perf.
>
> I've not found a platform that can test all the behaviours around the monitors,
> so this is where I'd expect the most bugs.
>
> The MPAM spec that describes all the system and MMIO registers can be found here:
> https://developer.arm.com/documentation/ddi0598/db/?lang=en
> (Ignored the 'RETIRED' warning - that is just arm moving the documentation around.
>  This document has the best overview)
>
> The expectation is this will go via the arm64 tree.
>
> This series is based on v6.18-rc4, and can be retrieved from: (no v6 version)
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/driver/v5
>
> The rest of the driver can be found here: (no v6 version)
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/snapshot/v6.18-rc4-v5
>
> What is MPAM? Set your time-machine to 2020:
> https://lore.kernel.org/lkml/20201030161120.227225-1-james.morse@arm.com/

Although a little late to the party, I've managed to throw together
enough firmware to describe the MPAM hardware and take this set (more
specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository)
for a spin. Using the branch, the kernel is able to probe the hardware
and discover the advertised features. Yay! We are in business.

Having said that, there are a few quirks of the platform that run into
issues with later patches in the branch. The platform has MSCs attached
to shared L2 caches which are being skipped during later stages of
initialisation. IIUC, the L2 MSCs' limitations stems from the
assumptions in the resctrl interface.

I was wondering if there are any patches available to relax these
limitations? I can give them a try. Or do these need to be put together
from the ground up? Any pointers greatly appreciated.

Thanks,
Punit

[...]

Hi Punit,

On 11/24/25 15:21, Punit Agrawal wrote:
> Hi Ben, James
> 
> Ben Horgan <ben.horgan@arm.com> writes:
> 
>>
>> This series is based on v6.18-rc4, and can be retrieved from: (no v6 version)
>> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/driver/v5
>>
>> The rest of the driver can be found here: (no v6 version)
>> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/snapshot/v6.18-rc4-v5
>>
>> What is MPAM? Set your time-machine to 2020:
>> https://lore.kernel.org/lkml/20201030161120.227225-1-james.morse@arm.com/
> 
> Although a little late to the party, I've managed to throw together
> enough firmware to describe the MPAM hardware and take this set (more
> specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository)
> for a spin. Using the branch, the kernel is able to probe the hardware
> and discover the advertised features. Yay! We are in business.

Thanks for giving it a go. :)

> 
> Having said that, there are a few quirks of the platform that run into
> issues with later patches in the branch. The platform has MSCs attached
> to shared L2 caches which are being skipped during later stages of
> initialisation. IIUC, the L2 MSCs' limitations stems from the
> assumptions in the resctrl interface.

What in particualar is being skipped?

> 
> I was wondering if there are any patches available to relax these
> limitations? I can give them a try. Or do these need to be put together
> from the ground up? Any pointers greatly appreciated.

There are some extra things added in the extras branch [1] e.g. cache
maximum usage controls (cmax). However, lots of possible things are
still missing e.g. any monitors on L2. If it doesn't fit with the
topology expected by resctrl then it is unlikely to have been considered
yet.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam/snapshot%2bextras/v6.18-rc1

Thanks,

Ben

Hi Ben,

Thanks for getting back.

Ben Horgan <ben.horgan@arm.com> writes:

> Hi Punit,
>
> On 11/24/25 15:21, Punit Agrawal wrote:
>> Hi Ben, James
>> 
>> Ben Horgan <ben.horgan@arm.com> writes:
>> 
>>>
>>> This series is based on v6.18-rc4, and can be retrieved from: (no v6 version)
>>> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/driver/v5
>>>
>>> The rest of the driver can be found here: (no v6 version)
>>> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/snapshot/v6.18-rc4-v5
>>>
>>> What is MPAM? Set your time-machine to 2020:
>>> https://lore.kernel.org/lkml/20201030161120.227225-1-james.morse@arm.com/
>> 
>> Although a little late to the party, I've managed to throw together
>> enough firmware to describe the MPAM hardware and take this set (more
>> specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository)
>> for a spin. Using the branch, the kernel is able to probe the hardware
>> and discover the advertised features. Yay! We are in business.
>
> Thanks for giving it a go. :)
>
>> 
>> Having said that, there are a few quirks of the platform that run into
>> issues with later patches in the branch. The platform has MSCs attached
>> to shared L2 caches which are being skipped during later stages of
>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>> assumptions in the resctrl interface.
>
> What in particualar is being skipped?

The registration of the discovered MSCs with resctrl and subsequent
exposing it to the user.

>> I was wondering if there are any patches available to relax these
>> limitations? I can give them a try. Or do these need to be put together
>> from the ground up? Any pointers greatly appreciated.
>
> There are some extra things added in the extras branch [1] e.g. cache
> maximum usage controls (cmax). However, lots of possible things are
> still missing e.g. any monitors on L2. If it doesn't fit with the
> topology expected by resctrl then it is unlikely to have been considered
> yet.

Thanks for the pointer. I'll give the snapshot+extras branch[1] a try.

The platform does have both controls and monitors attached to L2. If
this isn't being looked at, I can try and put something together. Thanks
for confirming that the limitation is likely due to resctrl.

Looking forward to the next set of MPAM support landing.

> [1] https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam/snapshot%2bextras/v6.18-rc1

[...]

Hi Punit,

On 03/12/2025 11:21, Punit Agrawal wrote:
> Ben Horgan <ben.horgan@arm.com> writes:
>> On 11/24/25 15:21, Punit Agrawal wrote:
>>> Although a little late to the party,

There was a party?!


>>> I've managed to throw together
>>> enough firmware to describe the MPAM hardware and take this set (more
>>> specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository)
>>> for a spin. Using the branch, the kernel is able to probe the hardware
>>> and discover the advertised features. Yay! We are in business.
>>
>> Thanks for giving it a go. :)
>>
>>>
>>> Having said that, there are a few quirks of the platform that run into
>>> issues with later patches in the branch.

So something in the resctrl support code is causing this.
Any idea which patch causes this to happen?

There are a load of pr_debug() in the picking logic, if you enable DYNDEBUG and add:
| dyndbg="file mpam_resctrl.c +pl"

to the commandline, you should get some snotty messages about what non-Xeon-like property
your platform has.



>>> The platform has MSCs attached
>>> to shared L2 caches which are being skipped during later stages of
>>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>>> assumptions in the resctrl interface.
>>
>> What in particualar is being skipped?

> The registration of the discovered MSCs with resctrl and subsequent
> exposing it to the user.

resctrl's 'L2' support is limited to the CPOR bitmap.
If you have controls, there is no resctrl 'event' that can exposed them.
(the problem being they all have 'L3' in the name!)


>>> I was wondering if there are any patches available to relax these
>>> limitations?

Knowing which property it is will help - but some of these things are checked
to match resctrl's ABI. They can't necessarily be relaxed without breaking
user-space.

Others are sanity checks, e.g. all CPUs are represented. This is to avoid tasks
that run on cpu-9 escaping the resctrl controls. Platforms that did this may as
well not bother with resctrl at all.


>>> I can give them a try. Or do these need to be put together
>>> from the ground up? Any pointers greatly appreciated.
>>
>> There are some extra things added in the extras branch [1] e.g. cache
>> maximum usage controls (cmax). However, lots of possible things are
>> still missing e.g. any monitors on L2. If it doesn't fit with the
>> topology expected by resctrl then it is unlikely to have been considered
>> yet.
> 
> Thanks for the pointer. I'll give the snapshot+extras branch[1] a try.
> 
> The platform does have both controls and monitors attached to L2. If
> this isn't being looked at, I can try and put something together. Thanks
> for confirming that the limitation is likely due to resctrl.

My view on 'extra' counters is to try and expose them via perf, as this would also
allow platform specific counters. I worry that if we start adding 'easy' ones like
l2_mbm_total to resctrl, someone will want left_hand_side_of_soc_mbm_total.


Thanks,

James

James Morse <james.morse@arm.com> writes:

> Hi Punit,
>
> On 03/12/2025 11:21, Punit Agrawal wrote:
>> Ben Horgan <ben.horgan@arm.com> writes:
>>> On 11/24/25 15:21, Punit Agrawal wrote:
>>>> Although a little late to the party,
>
> There was a party?!
>
>
>>>> I've managed to throw together
>>>> enough firmware to describe the MPAM hardware and take this set (more
>>>> specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository)
>>>> for a spin. Using the branch, the kernel is able to probe the hardware
>>>> and discover the advertised features. Yay! We are in business.
>>>
>>> Thanks for giving it a go. :)
>>>
>>>>
>>>> Having said that, there are a few quirks of the platform that run into
>>>> issues with later patches in the branch.
>
> So something in the resctrl support code is causing this.
> Any idea which patch causes this to happen?
>
> There are a load of pr_debug() in the picking logic, if you enable DYNDEBUG and add:
> | dyndbg="file mpam_resctrl.c +pl"
>
> to the commandline, you should get some snotty messages about what non-Xeon-like property
> your platform has.

Thanks - I've got this enabled.

The platform looks very different to a Xeon. One notable difference
being a shared L2. Hence all the MSCs attached there.

>>>> The platform has MSCs attached
>>>> to shared L2 caches which are being skipped during later stages of
>>>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>>>> assumptions in the resctrl interface.
>>>
>>> What in particualar is being skipped?
>
>> The registration of the discovered MSCs with resctrl and subsequent
>> exposing it to the user.
>
> resctrl's 'L2' support is limited to the CPOR bitmap.
> If you have controls, there is no resctrl 'event' that can exposed them.
> (the problem being they all have 'L3' in the name!)

>>>> I was wondering if there are any patches available to relax these
>>>> limitations?

> Knowing which property it is will help - but some of these things are checked
> to match resctrl's ABI. They can't necessarily be relaxed without breaking
> user-space.

This platform has portion, capacity and priority partitioning, as well
as memory bandwidth and cache storage monitoring. The MPAM code seems to
correctly parse the properties.

But as you point out, the resctrl 'L2' support doesn't have anything
other than CPOR bitmap yet. Have you looked at what's needed to extend
resctrl to support some of the others?

> Others are sanity checks, e.g. all CPUs are represented. This is to avoid tasks
> that run on cpu-9 escaping the resctrl controls. Platforms that did this may as
> well not bother with resctrl at all.
>
>
>>>> I can give them a try. Or do these need to be put together
>>>> from the ground up? Any pointers greatly appreciated.
>>>
>>> There are some extra things added in the extras branch [1] e.g. cache
>>> maximum usage controls (cmax). However, lots of possible things are
>>> still missing e.g. any monitors on L2. If it doesn't fit with the
>>> topology expected by resctrl then it is unlikely to have been considered
>>> yet.
>> 
>> Thanks for the pointer. I'll give the snapshot+extras branch[1] a try.
>> 
>> The platform does have both controls and monitors attached to L2. If
>> this isn't being looked at, I can try and put something together. Thanks
>> for confirming that the limitation is likely due to resctrl.
>
> My view on 'extra' counters is to try and expose them via perf, as this would also
> allow platform specific counters. I worry that if we start adding 'easy' ones like
> l2_mbm_total to resctrl, someone will want
> left_hand_side_of_soc_mbm_total.

I wouldn't club L2 in the same category as 'left_hand_side_of_soc'. You
call it 'easy' for a reason. L2 is pretty well understood and resctrl
already exposes an interface for it. I would avoid creating a new
interface for users.

For some of the other boundaries, things like 'left_hand_side_of_soc' I
wonder if firmware provided topology (e.g., PPTT, SRAT, etc) could be
used to make even this work.

Hi Punit,

On 12/5/25 5:08 AM, Punit Agrawal wrote:
> James Morse <james.morse@arm.com> writes:
>> On 03/12/2025 11:21, Punit Agrawal wrote:
>>> Ben Horgan <ben.horgan@arm.com> writes:
>>>> On 11/24/25 15:21, Punit Agrawal wrote:

>>>>> The platform has MSCs attached
>>>>> to shared L2 caches which are being skipped during later stages of
>>>>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>>>>> assumptions in the resctrl interface.
>>>>
>>>> What in particualar is being skipped?
>>
>>> The registration of the discovered MSCs with resctrl and subsequent
>>> exposing it to the user.
>>
>> resctrl's 'L2' support is limited to the CPOR bitmap.
>> If you have controls, there is no resctrl 'event' that can exposed them.
>> (the problem being they all have 'L3' in the name!)
> 
>>>>> I was wondering if there are any patches available to relax these
>>>>> limitations?
> 
>> Knowing which property it is will help - but some of these things are checked
>> to match resctrl's ABI. They can't necessarily be relaxed without breaking
>> user-space.
> 
> This platform has portion, capacity and priority partitioning, as well
> as memory bandwidth and cache storage monitoring. The MPAM code seems to
> correctly parse the properties.
> 
> But as you point out, the resctrl 'L2' support doesn't have anything
> other than CPOR bitmap yet. Have you looked at what's needed to extend
> resctrl to support some of the others?

Please see [1] for a summary of ideas on how resctrl can support multiple
controls. Nothing is final, please do add your ideas and requirements.

There are a couple of opens not included in the summary. If interested
[2] is where a lot of discussion happened that prompted the need for
a summary.

Reinette

[1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/
[2] https://lore.kernel.org/lkml/aNFliMZTTUiXyZzd@e133380.arm.com/

Hi Reinette,

Reinette Chatre <reinette.chatre@intel.com> writes:

> Hi Punit,
>
> On 12/5/25 5:08 AM, Punit Agrawal wrote:
>> James Morse <james.morse@arm.com> writes:
>>> On 03/12/2025 11:21, Punit Agrawal wrote:
>>>> Ben Horgan <ben.horgan@arm.com> writes:
>>>>> On 11/24/25 15:21, Punit Agrawal wrote:
>
>>>>>> The platform has MSCs attached
>>>>>> to shared L2 caches which are being skipped during later stages of
>>>>>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>>>>>> assumptions in the resctrl interface.
>>>>>
>>>>> What in particualar is being skipped?
>>>
>>>> The registration of the discovered MSCs with resctrl and subsequent
>>>> exposing it to the user.
>>>
>>> resctrl's 'L2' support is limited to the CPOR bitmap.
>>> If you have controls, there is no resctrl 'event' that can exposed them.
>>> (the problem being they all have 'L3' in the name!)
>> 
>>>>>> I was wondering if there are any patches available to relax these
>>>>>> limitations?
>> 
>>> Knowing which property it is will help - but some of these things are checked
>>> to match resctrl's ABI. They can't necessarily be relaxed without breaking
>>> user-space.
>> 
>> This platform has portion, capacity and priority partitioning, as well
>> as memory bandwidth and cache storage monitoring. The MPAM code seems to
>> correctly parse the properties.
>> 
>> But as you point out, the resctrl 'L2' support doesn't have anything
>> other than CPOR bitmap yet. Have you looked at what's needed to extend
>> resctrl to support some of the others?
>
> Please see [1] for a summary of ideas on how resctrl can support multiple
> controls. Nothing is final, please do add your ideas and requirements.
>
> There are a couple of opens not included in the summary. If interested
> [2] is where a lot of discussion happened that prompted the need for
> a summary.

Thanks a lot for the pointers.

Let me catch up with what's already discussed and raise any points that
are not clear / need refining.

>
> Reinette
>
> [1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/
> [2] https://lore.kernel.org/lkml/aNFliMZTTUiXyZzd@e133380.arm.com/

Hi Punit,

On 12/8/25 9:43 AM, Punit Agrawal wrote:
> Hi Reinette,
> 
> Reinette Chatre <reinette.chatre@intel.com> writes:
> 
>> Hi Punit,
>>
>> On 12/5/25 5:08 AM, Punit Agrawal wrote:
>>> James Morse <james.morse@arm.com> writes:
>>>> On 03/12/2025 11:21, Punit Agrawal wrote:
>>>>> Ben Horgan <ben.horgan@arm.com> writes:
>>>>>> On 11/24/25 15:21, Punit Agrawal wrote:
>>
>>>>>>> The platform has MSCs attached
>>>>>>> to shared L2 caches which are being skipped during later stages of
>>>>>>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>>>>>>> assumptions in the resctrl interface.
>>>>>>
>>>>>> What in particualar is being skipped?
>>>>
>>>>> The registration of the discovered MSCs with resctrl and subsequent
>>>>> exposing it to the user.
>>>>
>>>> resctrl's 'L2' support is limited to the CPOR bitmap.
>>>> If you have controls, there is no resctrl 'event' that can exposed them.
>>>> (the problem being they all have 'L3' in the name!)
>>>
>>>>>>> I was wondering if there are any patches available to relax these
>>>>>>> limitations?
>>>
>>>> Knowing which property it is will help - but some of these things are checked
>>>> to match resctrl's ABI. They can't necessarily be relaxed without breaking
>>>> user-space.
>>>
>>> This platform has portion, capacity and priority partitioning, as well
>>> as memory bandwidth and cache storage monitoring. The MPAM code seems to
>>> correctly parse the properties.
>>>
>>> But as you point out, the resctrl 'L2' support doesn't have anything
>>> other than CPOR bitmap yet. Have you looked at what's needed to extend
>>> resctrl to support some of the others?
>>
>> Please see [1] for a summary of ideas on how resctrl can support multiple
>> controls. Nothing is final, please do add your ideas and requirements.
>>
>> There are a couple of opens not included in the summary. If interested
>> [2] is where a lot of discussion happened that prompted the need for
>> a summary.
> 
> Thanks a lot for the pointers.
> 
> Let me catch up with what's already discussed and raise any points that
> are not clear / need refining.

Please do. There are already a few known open issues. I plan to raise awareness
of these discussions (and the (so far known) sticky points still left to resolve) during
the resctrl session at LPC:
https://lpc.events/event/19/contributions/2093/

I am attending LPC remotely though so I hope increased awareness will result in more traffic
to [1] to help us get this right.

Reinette


> 
>>
>> Reinette
>>
>> [1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/
>> [2] https://lore.kernel.org/lkml/aNFliMZTTUiXyZzd@e133380.arm.com/

From: Catalin Marinas <catalin.marinas@arm.com>

On Wed, 19 Nov 2025 12:22:30 +0000, Ben Horgan wrote:
> Just a handful of minor changes based on v5 review comments. See individual
> patches for change lgos. I haven't asked James to host any branches for this
> revision but please let me know if this would be helpful to anyone. Thanks for
> all the help with reviews and testing.
> 
> Previous cover letter from James:
> 
> [...]

I queued the series on a branch to give it a bit of exposure in -next
for the next 10 days or so. If nothing falls apart, it should go
upstream but there's always a risk of the series being dropped at short
notice. I aim to keep the branch stable and only apply fixups on top if
needed.

Greg, I haven't got any acks from you, I assume you don't have any
objections (please let me know otherwise).

Applied to arm64 (for-next/mpam), thanks!

[01/34] ACPI / PPTT: Add a helper to fill a cpumask from a processor container
        https://git.kernel.org/arm64/c/796e29b857ae
[02/34] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels
        https://git.kernel.org/arm64/c/eeec7845e966
[03/34] ACPI / PPTT: Add acpi_pptt_cache_v1_full to use pptt cache as one structure
        https://git.kernel.org/arm64/c/cfc085af8398
[04/34] ACPI / PPTT: Find cache level by cache-id
        https://git.kernel.org/arm64/c/41a7bb39fede
[05/34] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id
        https://git.kernel.org/arm64/c/a39a723a6f1e
[06/34] arm64: kconfig: Add Kconfig entry for MPAM
        https://git.kernel.org/arm64/c/d8bf01d80919
[07/34] platform: Define platform_device_put cleanup handler
        https://git.kernel.org/arm64/c/f5915600cc4c
[08/34] ACPI: Define acpi_put_table cleanup handler and acpi_get_table_pointer() helper
        https://git.kernel.org/arm64/c/96f4a4d53e66
[09/34] ACPI / MPAM: Parse the MPAM table
        https://git.kernel.org/arm64/c/115c5325beae
[10/34] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate
        https://git.kernel.org/arm64/c/f04046f2577a
[11/34] arm_mpam: Add the class and component structures for firmware described ris
        https://git.kernel.org/arm64/c/01fb4b822472
[12/34] arm_mpam: Add MPAM MSC register layout definitions
        https://git.kernel.org/arm64/c/aa64b9e11051
[13/34] arm_mpam: Add cpuhp callbacks to probe MSC hardware
        https://git.kernel.org/arm64/c/8f8d0ac1da78
[14/34] arm_mpam: Probe hardware to find the supported partid/pmg values
        https://git.kernel.org/arm64/c/bd221f9f82af
[15/34] arm_mpam: Add helpers for managing the locking around the mon_sel registers
        https://git.kernel.org/arm64/c/d02beb06ca2a
[16/34] arm_mpam: Probe the hardware features resctrl supports
        https://git.kernel.org/arm64/c/8c90dc68a5de
[17/34] arm_mpam: Merge supported features during mpam_enable() into mpam_class
        https://git.kernel.org/arm64/c/c10ca83a7783
[18/34] arm_mpam: Reset MSC controls from cpuhp callbacks
        https://git.kernel.org/arm64/c/f188a36ca241
[19/34] arm_mpam: Add a helper to touch an MSC from any CPU
        https://git.kernel.org/arm64/c/475228d15dd6
[20/34] arm_mpam: Extend reset logic to allow devices to be reset any time
        https://git.kernel.org/arm64/c/3bd04fe7d807
[21/34] arm_mpam: Register and enable IRQs
        https://git.kernel.org/arm64/c/49aa621c4dca
[22/34] arm_mpam: Use a static key to indicate when mpam is enabled
        https://git.kernel.org/arm64/c/3796f75aa795
[23/34] arm_mpam: Allow configuration to be applied and restored during cpu online
        https://git.kernel.org/arm64/c/09b89d2a72f3
[24/34] arm_mpam: Probe and reset the rest of the features
        https://git.kernel.org/arm64/c/880df85d8673
[25/34] arm_mpam: Add helpers to allocate monitors
        https://git.kernel.org/arm64/c/c891bae66423
[26/34] arm_mpam: Add mpam_msmon_read() to read monitor value
        https://git.kernel.org/arm64/c/823e7c3712c5
[27/34] arm_mpam: Track bandwidth counter state for power management
        https://git.kernel.org/arm64/c/41e8a14950e1
[28/34] arm_mpam: Consider overflow in bandwidth counter state
        https://git.kernel.org/arm64/c/b35363793291
[29/34] arm_mpam: Probe for long/lwd mbwu counters
        https://git.kernel.org/arm64/c/fdc29a141d63
[30/34] arm_mpam: Use long MBWU counters if supported
        https://git.kernel.org/arm64/c/9e5afb7c3283
[31/34] arm_mpam: Add helper to reset saved mbwu state
        https://git.kernel.org/arm64/c/201d96ca4c86
[32/34] arm_mpam: Add kunit test for bitmap reset
        https://git.kernel.org/arm64/c/e3565d1fd4dc
[33/34] arm_mpam: Add kunit tests for props_mismatch()
        https://git.kernel.org/arm64/c/2557e0eafec1
[34/34] MAINTAINERS: new entry for MPAM Driver
        https://git.kernel.org/arm64/c/ce1e1421f8d8

-- 
Catalin