[linux-nvidia-6.18-next] Backport MPAM Support#487
Open
ltrager wants to merge 92 commits into
Open
Conversation
Dan has reported two uses of uninitialized variables in __ris_msmon_read(). If an unknown monitor type is encountered then the local variable, now, is used uninitialized. Fix this by returning early on error. If a non-mbwu monitor is being read then the local variable, overflow, is not initialized but still read. Initialize it to false as overflow is not relevant for csu monitors. Fixes: 823e7c3 ("arm_mpam: Add mpam_msmon_read() to read monitor value") Fixes: 9e5afb7 ("arm_mpam: Use long MBWU counters if supported") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202512091519.RBwiJcSq-lkp@intel.com/ Closes: https://lore.kernel.org/r/202512100547.N7QPYgfb-lkp@intel.com/ Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit c2803bd) Signed-off-by: Lee Trager <ltrager@nvidia.com>
./drivers/resctrl/mpam_internal.h: linux/srcu.h is included more than once. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=27328 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by: James Morse <james.morse@arm.com> [BH: Keep alphabetical order] Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (backported from commit b5a69c4) [ltrager: minor conflict in header order] Signed-off-by: Lee Trager <ltrager@nvidia.com>
In the test__props_mismatch() kunit test we rely on the struct mpam_props being packed to ensure memcmp doesn't consider packing. Making it packed reduces the alignment of the features bitmap and so breaks a requirement for the use of atomics. As we don't rely on the set/clear of these bits being atomic, just make them non-atomic. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Fixes: 8c90dc6 ("arm_mpam: Probe the hardware features resctrl supports") Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit b9f5c38) Signed-off-by: Lee Trager <ltrager@nvidia.com>
When an MSC supporting memory bandwidth monitoring is brought offline and then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to restore the configuration of the bandwidth counters. It doesn't care about the value read, mbwu_arg.val, and doesn't set it leading to a null pointer dereference when __ris_msmon_read() adds to it. This results in a kernel oops with a call trace such as: Call trace: __ris_msmon_read+0x19c/0x64c (P) mpam_restore_mbwu_state+0xa0/0xe8 smp_call_on_cpu_callback+0x1c/0x38 process_one_work+0x154/0x4b4 worker_thread+0x188/0x310 kthread+0x11c/0x130 ret_from_fork+0x10/0x20 Provide a local variable for val to avoid __ris_msmon_read() dereferencing a null pointer when adding to val. Fixes: 41e8a14 ("arm_mpam: Track bandwidth counter state for power management") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will@kernel.org> (cherry picked from commit 4ad79c8) Signed-off-by: Lee Trager <ltrager@nvidia.com>
The MPAM ACPI table lists the MPAM MSCs and indicates which resources in the system they control. Not everything this table can describe is supported by resctrl, e.g. memory-side-caches. Add the additional table parsing to avoid reporting these as 'unknown' to the MPAM driver. This allows class+component hierarchys to be built. Until resctrl has support for any of these resources, users would be in-kernel managers of a resource/PARTID or perf to query bandwidth counters on a resource resctrl is unaware of. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20260429141339.3171205-2-andre.przywara@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
The MSC MON_SEL register needs to be accessed from hardirq for the overflow interrupt, and when taking an IPI to access these registers on platforms where MSC are not accesible from every CPU. This makes an irqsave spinlock the obvious lock to protect these registers. On systems with SCMI mailboxes it must be able to sleep, meaning a mutex must be used. The SCMI platforms can't support an overflow interrupt. Clearly these two can't exist for one MSC at the same time. Split the existing helper into a raw spinlock and a mutex, named inner and outer. The outer lock must be taken in an a pre-emptible context befroe the inner lock can be taken. On systems with SCMI mailboxes where the MON_SEL accesses must sleep - the inner lock will fail tobe taken if the caller is unable to sleep. This will allow callers to fail withuot having to explicitly check the interface type of each MSC. Signed-off-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20260429141339.3171205-3-andre.przywara@arm.com [ltrager: - dropped the mpam_mon_sel_outer_lock()/unlock() pair around mpam_reprogram_msc()'s loop; mpam_restore_mbwu_state() (run via smp_call_on_cpu) takes that mutex itself, so holding it here deadlocks at boot ] Signed-off-by: Lee Trager <ltrager@nvidia.com>
The Arm MPAM Firmware-backed (Fb) Profile document[1] describes an alternative way of accessing the "Memory System Components" (MSC) in an MPAM enabled system. Normally the MSCs are MMIO mapped, but in some implementations this might not be possible (MSC located outside of the local socket, MSC mapped secure-only) or desirable (direct MMIO access too slow or needs to be mediated through a control processor). MPAM-fb standardises a protocol to abstract MSC accesses, building on the SCMI protocol. Add functions that do an MSC read or write access by redirecting the request through a firmware interface. For now this done via an ACPI PCC shared memory and mailbox combination. Since the protocol used is only a small subset of the full SCMI spec, and the SCMI protocol has no full ACPI support anyway, open-code the SCMI message generation and handshake, for just the fields we need. [1] https://developer.arm.com/documentation/den0144/latest Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20260429141339.3171205-4-andre.przywara@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
When an MPAM MSC gets into an error condition, it can trigger an error IRQ. We cannot really do much about those errors, but we at least query and log the error, then disable MPAM functionality. This error report relies on reading the MSC's error status register (ESR) in the IRQ handler, which is not possible for MPAM-Fb based MSC accesses, since they involve mailbox routines that might sleep. For simplicity just skip the ESR read when the MSC is not using direct MMIO accesses. We will wrap up MPAM functionality regardless, knowing the exact error value will not change that. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20260429141339.3171205-5-andre.przywara@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
The Arm MPAM-Fb specification [1] describes a protocol to access MSC registers through a firmware interface. This requires a shared memory region to hold the message, and a mailbox to trigger the access. For ACPI this is wrapped as a PCC channel, described using existing ACPI abstractions. Add code to parse those PCC table descriptions associated with an MSC, and store the parsed information in the MSC struct. This will be used by the MPAM-Fb access wrapper code. [1] https://developer.arm.com/documentation/den0144/latest Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20260429141339.3171205-6-andre.przywara@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
The error path in resctrl_mkdir_event_configs() is unnecessarily complicated. Simplify it to just return directly on error. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/r/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit 7625632 linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
…configurable When the counter assignment mode is mbm_event resctrl assumes the MBM events are configurable and exposes the 'event_filter' files. These files live at info/L3_MON/event_configs/<event>/event_filter and are used to display and set the event configuration. The MPAM architecture has support for configuring the memory bandwidth utilization (MBWU) counters to only count reads or only count writes. However, in MPAM, this event filtering support is optional in the hardware (and not yet implemented in the MPAM driver) but MBM counter assignment is always possible for MPAM MBWU counters. In order to support mbm_event mode with MPAM, create the 'event_filter' files read only if the event configuration can't be changed. A user can still chmod the file and so also return early with an error from event_filter_write(). Introduce a new monitor property, mbm_cntr_configurable, to indicate whether or not assignable MBM counters are configurable. On x86, set this to true whenever mbm_cntr_assignable is true to keep existing behaviour. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit 94a1206 linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
…signable The software controller requires that there is one MBM counter per monitor group that is assigned to the event backing the software controller, as per mba_MBps_event. When mbm_event mode is in use, it is not guaranteed that any particular event will have an assigned counter. Currently, only AMD systems support counter assignment, but the MBA delay is non-linear and so the software controller is never supported anyway. On MPAM systems, the MBA delay is linear and so the software controller could be supported. The MPAM driver, unless a need arises, will not support the 'default' mbm_assign_mode and will always use the 'mbm_event' mode for memory bandwidth monitoring. Rather than develop a way to guarantee the counter assignment requirements needed by the software controller, take the pragmatic approach. Don't allow the software controller to be used at the same time as 'mbm_event' mode. As MPAM is the only relevant architecture and it will use 'mbm_event' mode whenever there are assignable MBM counters, for simplicity's sake, don't allow the software controller when the MBM counters are assignable. Implement this by failing the mount if the user requests the software controller, the mba_MBps option, and the MBM counters are assignable. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit f52abe6 linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Commit 3b497c3 ("fs/resctrl: Introduce the interface to display monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but left adding the Kconfig entry until it was necessary. The counter assignment mode is fixed in MPAM, even when there are assignable counters, and so addressing this is needed to support MPAM. To avoid the burden of another Kconfig entry, replace CONFIG_RESCTRL_ASSIGN_FIXED with a new property in 'struct resctrl_mon', 'mbm_cntr_assign_fixed' to be set by the architecture. Do not request the architecture to change the counter assignment mode if it does not support doing so. Provide insight to user space about why such a request fails. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit ee3d4c8 linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
In mbm_event mode, with mbm_assign_on_mkdir set to 1, when a user creates a new CTRL_MON or MON group resctrl attempts to allocate counters for each of the supported MBM events on each resctrl domain. As counters are limited, such allocation may fail and when it does counter allocations for the remaining domains are skipped even if the domains have available counters. Because of that, the user needs to view the resource group'smbm_L3_assignments file to get an accurate view of counter assignment in a new resource group and then manually create counters in the skipped domains with available counters. Writes to mbm_L3_assignments using the wildcard format, <event>:*=e, also skip counter allocation in other domains after a counter allocation failure. When handling a request to create counters in all domains it is unnecessary for a counter allocation in one domain to prevent counter allocation in other domains. Always attempt to allocate all the counters requested. [ bp: Massage commit message. ] Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit 3aec86e linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
When using automatic counter assignment it's useful for a user to know which counters they can expect to be assigned on group creation. Document that automatic counter assignment is best effort and how to discover any assignment failures. Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit 9a16462 linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
When 0 is written to the tasks file it is interpreted as the current task in rdtgroup_move_task(). Each CPU's idle task has task_struct::pid set to 0 and, on x86, task_struct::closid to RESCTRL_RESERVED_CLOSID and task_struct::rmid to RESCTRL_RESERVED_RMID. Equivalently, on MPAM platforms, thread_info::mpam_partid_pmg is encoded with PARTID and PMG set to RESCTRL_RESERVED_CLOSID and RESCTRL_RESERVED_RMID, respectively. As there is no interface to change these from the default, the resctrl configuration for the idle tasks is fixed and they always behave equivalently to a task in the default tasks file and so take their configuration from the cpus/cpus_list files. On read of the tasks file, show_rdt_tasks() filters out any 0 PID. Hence, a task id of 0 is never shown in the tasks file and the idle tasks are not represented either. Document the user visible behaviour. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com (cherry picked from commit 1cfa74c linux-next) Signed-off-by: Lee Trager <ltrager@nvidia.com>
resctrl has two types of bandwidth counters, NUMA-local and global. MPAM can only count globally; either using MSC at the L3 cache or in the memory controllers. When global and local equate to the same thing continue just to call it global. Pick the corresponding MPAM classes to back the MBM counters. As resctrl requires all monitors to be at the L3 cache, we can only use the counters at the memory controllers when they have the same topology as the L3 cache and the traffic they see if the same. In particular, for the bandwidth counters at the memory controllers to be exposed to resctrl it is required there is a single L3 cache and a single NUMA node as otherwise cross NUMA traffic will be counted at the wrong instance. Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Link: https://lore.kernel.org/r/20260520212458.1797221-2-ben.horgan@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory bandwidth monitors assignable. Rather than supporting the 'default' mbm_assign_mode always use 'mbm_event' mode even if there are sufficient memory bandwidth monitors. The per monitor event configuration is only provided by resctrl when in 'mbm_event' mode and so only allowing 'mbm_event' mode will make it easier to support per-monitor event configuration for MPAM. For the moment, the only event supported is mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode' file will still show 'default' when there is no support for memory bandwidth monitoring. The monitors need to be allocated from the driver, and mapped to whichever control/monitor group resctrl wants to use them with. Add a second array to hold the monitor values indexed by resctrl's cntr_id. When CDP is in use, two monitors are needed so the available number of counters halves. Platforms with one monitor will have zero monitors when CDP is in use. Co-developed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Link: https://lore.kernel.org/r/20260520212458.1797221-3-ben.horgan@arm.com [ltrager: Add flag for kvmalloc_objs required in 6.18] Signed-off-by: Lee Trager <ltrager@nvidia.com>
…ABMC use ABMC, mbm_event mode, has a helper resctrl_arch_config_cntr() for changing the mapping between 'cntr_id' and a CLOSID/RMID pair. Add the helper. For MPAM this is done by updating the mon->mbwu_idx_to_mon[] array, and as usual CDP means it needs doing in three different ways. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Link: https://lore.kernel.org/r/20260520212458.1797221-4-ben.horgan@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
…trl_arch_reset_cntr() When used in 'mbm_event' mode, ABMC emulation, resctrl uses arch hooks to read and reset the memory bandwidth utilization (MBWU) counters. Add these. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Link: https://lore.kernel.org/r/20260520212458.1797221-5-ben.horgan@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
…tation Memory bandwidth monitoring make uses of MBWU monitors and is now exposed to the user via resctrl. Add some documentation so the user knows what to expect. Co-developed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Link: https://lore.kernel.org/r/20260520212458.1797221-6-ben.horgan@arm.com Signed-off-by: Lee Trager <ltrager@nvidia.com>
The last_cmd_status file is intended to report details about the most recent resctrl filesystem operation, specifically to aid in diagnosing failures. However, when parsing io_alloc_cbm, if a user provides a domain ID that does not exist in the resource, the operation fails with -EINVAL without updating last_cmd_status. This results in inconsistent behaviour where the system call returns an error, but last_cmd_status misleadingly reports "ok", leaving the user unaware that the failure was caused by an invalid domain ID. Write an error message to last_cmd_status when the target domain ID cannot be found. Fixes: 28fa2cc ("fs/resctrl: Introduce interface to modify io_alloc capacity bitmasks") Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://patch.msgid.link/20260325001159.447075-2-atomlin@atomlin.com (cherry picked from commit d06b8e7) Signed-off-by: Lee Trager <ltrager@nvidia.com>
The x86 maintainers handle the resctrl filesystem and x86 architectural resctrl code. Even so, the x86 maintainers are not part of the resctrl section and not returned when scripts/get_maintainer.pl is run on resctrl filesystem code. With patches flowing via x86 maintainers resctrl should also ensure it follows the tip rules. Add the x86 maintainer alias, x86@kernel.org, to the resctrl section to ensure x86 maintainers are included in associated resctrl submissions. Add a reference to the tip tree handbook to make it clear which rules resctrl follows. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/4c14dd82e81737c6413e10fe097475b1cc0886fc.1775576382.git.reinette.chatre@intel.com (cherry picked from commit c611752) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Using the stricter "./tools/docs/kernel-doc -Wall -v" to verify proper
formatting of documentation comments includes warnings related to return
markup on functions that are omitted during the default verification
checks. This stricter verification reports a couple of missing return
descriptions in resctrl:
Warning: .../fs/resctrl/rdtgroup.c:1536 No description found for return value of 'rdtgroup_cbm_to_size'
Warning: .../fs/resctrl/rdtgroup.c:3131 No description found for return value of 'mon_get_kn_priv'
Warning: .../fs/resctrl/rdtgroup.c:3523 No description found for return value of 'cbm_ensure_valid'
Warning: .../fs/resctrl/monitor.c:238 No description found for return value of 'resctrl_find_cleanest_closid'
Add the missing return descriptions.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/1c50b9f7c73251c007133590986f127e1af57780.1775576382.git.reinette.chatre@intel.com
(cherry picked from commit 7972701)
Signed-off-by: Lee Trager <ltrager@nvidia.com>
The code to set MBA's alloc_capable to true appears to be trying to restore alloc_capable on unmount. This can never work because resctrl_arch_set_cdp_enabled() is never invoked with RDT_RESOURCE_MBA as the rid parameter. Consequently, mpam_resctrl_controls[RDT_RESOURCE_MBA].cdp_enabled always remains false. The alloc_capable setting in resctrl_arch_set_cdp_enabled() is to re-enable MBA if the caller opts in to separate control values using CDP for this resource. This doesn't happen today. Add a comment to describe this. However a bug remains where MBA allocation is permanently disabled after the mount with CDP option. Remounting without CDP cannot restore the MBA partition capability. Add a check to re-enable MBA when CDP is disabled, which happens on unmount. Fixes: 6789fb9 ("arm_mpam: resctrl: Add CDP emulation") Signed-off-by: Zeng Heng <zengheng4@huawei.com> [ morse: Added comment for existing code, added hunk to fix this bug from Ben H ] Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit f758340) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is used in an 'if' condition when it may be uninitialized. Initialize it to NULL so that the check behaves correctly when no monitor components are found. Reported-by: Dan Carpenter <error27@gmail.com> Fixes: 264c285 ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 67c0a48) Signed-off-by: Lee Trager <ltrager@nvidia.com>
resctrl_mon_ctx_waiters is not used outside of this file, so make it static. This fixes the sparse warning: drivers/resctrl/mpam_resctrl.c:25:1: warning: symbol 'resctrl_mon_ctx_waiters' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603281842.c2K96tJA-lkp@intel.com/ Fixes: 2a3c79c ("arm_mpam: resctrl: Allow resctrl to allocate monitors") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 4d5bbba) Signed-off-by: Lee Trager <ltrager@nvidia.com>
…eractions ABMC exposes a fun corner case where a platform with one monitor can use ABMC for assignable counters - but not when CDP is enabled. Add some tests. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit a861a0f https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: - Resolve minor conflicts in `drivers/resctrl/test_mpam_resctrl.c`; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
…closid_num_dirty_rmid[] On MPAM systems if an error occurs the arhictecture code will call resctrl_exit(). This calls dom_data_exit() which takes the rdrgroup_mutex and kfree()s closid_num_dirty_rmid[]. It is possible that another syscall tries to access that same array in the meantime, but is blocked on the mutex. Once dom_data_exit() completes, that syscall will see a NULL pointer. Pull the IS_ENABLED() Kconfig checks into a helper and additionally check that the array has been allocated. This will cause callers to fallback to the regular CLOSID allocation strategy. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit b9be9ec https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: - Resolve minor conflicts in `fs/resctrl/monitor.c`; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
…rmid_ptrs[] On MPAM systems if an error occurs the arhictecture code will call resctrl_exit(). This calls dom_data_exit() which takes the rdrgroup_mutex and kfree()s rmid_ptrs[]. It is possible that another syscall tries to access that same array in the meantime, but is blocked on the mutex. Once dom_data_exit() completes, that syscall will see a NULL pointer. Make __rmid_entry() return NULL in this case. Neither __check_limbo() nor free_rmid() return an error, and can silently stop their work if this occurs. dom_data_init() has only just allocated the array and still holds the lock, so __rmid_entry() should never return NULL here. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit c1ac3a4 https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: - Resolve minor conflicts in `fs/resctrl/monitor.c`; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
Add mb_max_lim and arch_has_mb_max_lim to struct resctrl_membw with kernel-doc: MPAM MAX_LIM encoding (MPAMF_MBW_IDR), invalid elsewhere unless arch sets arch_has_mb_max_lim. (cherry picked from commit 7939f1e https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
When mpam_feat_mbw_max is present, set membw.mb_max_lim from cprops->mbw_max_lim and membw.arch_has_mb_max_lim so generic resctrl can expose max_lim. (forward ported from commit 05b9bc1 https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: - Resolve minor conflicts in `drivers/resctrl/mpam_resctrl.c`; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
…et state To allow an iommu_group to be moved between resctrl groups as if it were a CPU thread, the mpam driver needs to be able to set the partid and pmg for the iommu_group. Use the properties in the STE, as these only apply to one stream. The MPAM driver also needs to know the maximum partid and pmg values that the SMMU can generate. This allows it to determine the system-wide common supported range of values. Add a helper to return this id register. Tested-by: Amit Singh Tomar <amitsinght@marvell.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 46a241f45ca9b71abf900f31a0c89fcbf24c44c4 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Lee Trager <ltrager@nvidia.com>
To allow an iommu_group to be moved between resctrl groups as if it were a CPU thread, the mpam driver needs to be able to set the partid and pmg for the iommu_group. Add helpers that call the iommu driver's get/set methods for these parameters. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 5ee2d478b62586acf816699e3cc479f49b682a58 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Lee Trager <ltrager@nvidia.com>
…rtid and pmg SMMU that support MPAM can be configured to use a particular partid and pmg for a stream. The assignment of an iommu_group and its corresponding streams should be done via resctrl. Add helpers similar to setting a closid/rmid on a task. We need the same shifting if the CPUs are using CDP. The SMMU only takes one partid, conceptually its always making data accesses. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 2393c3cf73cf642b67533ade39094fb9dd9d053c https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Lee Trager <ltrager@nvidia.com>
…resctrl groups Arm's MPAM has support for assigning devices behind an IOMMU to a control or monitor group. This can be used for device-passthrough for a VM, or user-space drivers using VFIO to ensure the device is either in the same control group as the CPU threads. Alternatively, the iommu_group may be assigned to a different control group with preferential schema values. Extend the resctrl tasks file to include iommu_groups. These appear as 'iommu_group:0', where 0 is the group number that can be found from /sys/kernel/iommu_groups/. iommu_groups can be moved between resctrl groups by writing this string in the same way as tasks are moved. No state is preserved by resctrl, an iommu_group that disappears will no longer be listed as being part of a resctrl group. A new iommu_group will appear in the default group. Add helpers to list and move iommu_groups. Architecture specific helpers are used to apply the closid/rmid to the iommu_group due to the way MPAM emulates CDP. Tested-by: Amit Singh Tomar <amitsinght@marvell.com> Signed-off-by: James Morse <james.morse@arm.com> (backport from commit 98b622c413ee64b8e05f93f0ff5f8cf85776afba https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) [ltrager: Resolved merge conflict relating to magic numbers now defined as macros, additional log output in drivers/acpi/arm64/mpam.c] Signed-off-by: Lee Trager <ltrager@nvidia.com>
…the driver discovered Not all of MPAM is visible through the resctrl user-space interface. To make it easy to debug why certain devices were not exposed through resctrl, allow the properties of the devices to be read through debugfs. This adds an mpam directory to debugfs, and exposes the devices as well as the hierarchy that was built. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit e8f0f21 https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: - Resolve minor conflicts in `drivers/resctrl/mpam_devices.c`; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
MPAM has an error interrupt that can be triggered by an MSC when corrupt or out of range values are seen. The hardware only needs to raise an error interrupt if the error was detected, it is also permissible for the hardware to just use the corrupt or our of range value. All the reasons to raise an error indicate a software bug. When the error interrupt is triggered, the MPAM driver attempts to reset all the CPUs back to PARTID-0 and reset PARTID-0 to be unrestricted. This is done to ensure important tasks aren't accidentally given the performance of unimportant tasks. This teardown path in the driver is hard to trigger. Add a debugfs file to poke this manually. It is expected you have to reboot to make MPAM work again after this. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 2c4e1fe https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
…ugfs It's really popular to tie NRDY high, and then act surprised when the OS never reads the counters, because they aren't ready. The spec obliges hardware to clear this bit automatically before the firmware advertised timeout. To make it easier to find errant hardware, count the number of retries and expose that number in debugfs. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 4fa427c https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: - Resolve minor conflicts in `drivers/resctrl/mpam_devices.c`; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
Carl reports that some platforms use the same PCC channel for multiple MSCs, which leads to the driver not probing. Add a list that is searched each time a new channel is allocated. CC: Carl Worth <carl@os.amperecomputing.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit a9dade3 https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) [fenghuay: Resolve minor conflicts in `drivers/resctrl/mpam_devices.c`; ltrager: Resolve minor conflicts in mpam_devices.h and mpam_internal.h; ] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Signed-off-by: Lee Trager <ltrager@nvidia.com>
…y and cleanup Squash this into the previous patch once it has been tested... ... does anyone have a PCC platform that can take this for a spin? Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit c83dd7f https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
…r can overflow Resctrl has an overflow handler that runs on each domain every second to ensure that any overflow of the hardware counter is accounted for. MPAM can have counters as large as 63 bits, in which case there is no need to check for overflow. To allow the overflow handler to be disabled, determine if an overflow can happen. If a class is not implemented, or has the 63bit counter, it can't overflow. Signed-off-by: James Morse <james.morse@arm.com> (backported from commit 5cbe15bd6c1d393cf1ffe2b259a3be54a5345e1e) [ltrager: Minor merge conflict] Signed-off-by: Lee Trager <ltrager@nvidia.com>
Resctrl has an overflow handler that runs on each domain every second to ensure that any overflow of the hardware counter is accounted for. MPAM can have counters as large as 63 bits, in which case there is no need to check for overflow. Call the new arch helpers to determine this. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 72e375a https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
… setup A single MPAM class can contain multiple MSC components, and a CPU may be associated with more than one of them. Domain create/destroy only walked the first matching component, so controls and monitors were not installed for the rest. Traffic through those omitted components then had no resctrl domain and bandwidth accounting or schemata did not apply where expected. Iterate every component associated with a CPU on online/offline and key domain lookup and allocation by component so each MSC instance gets its own resctrl domain. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> (backported from commit 46160db from 26.04_linux-nvidia-bos) [ltrager: - Fold mpam_resctrl_abmc_enabled() to true in mpam_resctrl_monitor_sync_abmc_vals(); this tree's newer "Pre-allocate monitors" (99e9a2b) always uses mbm_event mode and has no such helper. - Keep the baseline's mbm_cntr_*/mbm_cntr_assign_fixed flags in mpam_resctrl_monitor_init_abmc() (only renamed l3 -> r); they are the newer upstream ABMC fs API not present in the source tree. ] Signed-off-by: Lee Trager <ltrager@nvidia.com>
There is no struct arm_smmu_domain context for domains configured with identity mappings. Use the device to obtain the necessary information to program PARTID and PMGID. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> (cherry picked from commit 23bcbda https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
… init
Add rdt_mb_max_lim_show() and the max_lim entry in res_common_files[].
Add mb_max_lim_init() to call resctrl_file_fflags_init("max_lim", ...)
when arch_has_mb_max_lim, and invoke it from resctrl_init() after
io_alloc_init().
(forward ported from commit be13cad https://github.com/NVIDIA/NV-Kernels 24.04_linux-nvidia-6.17-next)
[fenghuay:
- Resolve minor conflicts in `fs/resctrl/rdtgroup.c`;
ltrager:
- Call mb_max_lim_init() before resctrl_mon_init(), which 'Include all MSC
components' renamed from resctrl_l3_mon_resource_init().
]
Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
Signed-off-by: Lee Trager <ltrager@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 MPAMCFG_MBW_PBM is written from cfg if cfg has the MBW partition feature. It is reset when cfg does not have the MBW partition feature. But the register handling is reversed. This may cause an incorrect register setting. For example, during an MPAM reset, reset_cfg is empty (no MBW partition feature set), and cfg->mbw_pbm is 0. Instead of resetting MPAMCFG_MBW_PBM to all 1's, the current logic will set it to cfg->mbw_pbm, which is 0. Fix the issue by swapping the if/else branches. Fixes: a1cb657 ("arm_mpam: Reset when feature configuration bit unset") Reported-by: Matt Ochs <mochs@nvidia.com> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> (cherry picked from https://lore.kernel.org/lkml/20260607050925.252475-1-fenghuay@nvidia.com/) Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2156531 The kdump adoption backport preserves live STEs until device attach has been re-established. MPAM QoS updates can rewrite STE PARTID/PMG fields before deferred attach is resolved. That can modify an adopted live STE while DMA may still be in flight. Reject MPAM QoS updates while kdump adoption is active and the device still has attach_deferred set. The IOMMU core clears attach_deferred after a successful real attach, so normal MPAM updates are unchanged after the device is attached. Non-kdump boots are unchanged. Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Add local bytes counter in mpam_resctrl_counters[] to fix missing mbm_local_bytes monitoring on Grace. Add mon->assigned_counters check to enable mbm_L3_assignments config file on Grace. Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
… events BugLink: https://bugs.launchpad.net/bugs/2157922 When mbm_total_bytes is exposed on MBA for memory-level MSC monitors, resctrl_arch_mon_capable() must reflect mon_capable on the backing resource, not only L3. Also gate MBM counter auto-assign and unassign on each enabled event's resource so MBA-backed mbm_total_bytes gets ABMC setup on group create and cleanup on group delete. Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
Collaborator
Boro watcher review skippedThe PR watcher skips automatic boro reviews for changes with more than 50 commits. This change currently has 92 commits. To run the review anyway, ask Head: This comment is maintained by nv-pr-bot. It is updated when the watcher sees a newer head. |
Collaborator
|
I see some issues with provenance:
|
Collaborator
|
Adding to Seth findings:
This one is missing the morse tree link |
Collaborator
|
All 92 commits were reviewed. The mechanical quality is good — the large 1.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
Backport MPAM support to linux-nvidia-6.18-next. 26.04_linux-nvidia-bos and 24.04_linux-nvidia-6.17-next were used as references for which patches needed porting. Patches which have landed upstream or which have newer versions on the LKML were preferred. See spreadsheet for full details on patches.
I did not run Boro or other tools against these patches as they are already in use and did not want to diverge from what is already provided in 6.17, 7.0, or upstream.
Testing
Testing was done on a Vera host
Setup
Most test hosts have the kernel argument
arm64.nompamset. This must be removed from /boot/grub/grub.cfg before booting into an MPAM supported kernel. Once booted the resctrl filesystem must be mountedFenghua's Tests
Fenghua has a number of tests which he has used to verify MPAM across various kernels. I discovered a bug in the regex on one test which is fixed in fyu1#1
Greenlit
Greenlit currently has basic MPAM support. Greenlit testing was done with Koba's grace-vera-mpam-acpi-comparison branch which adds some additional testing.