From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 39CBB3EFD3E for ; Tue, 28 Apr 2026 13:04:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777381481; cv=none; b=knzds6To09vIv0+sM7UyumWhzvGl+6mvFRlUkHVZcr1oGPNLOYxFkDqicskw8MgJAjtdqno11HBuj4UxOuU2t/j+ofmtKzHVM36SCY7jLT4uFn0C7j7ah7XEfEWmPbdVGLLQSVVA96enlpeoPtjz531ayRfofPJ7iza9t4cN42k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777381481; c=relaxed/simple; bh=uAgjSu2NegFUXZBzIZbFe/q82XldYP83Lc5mWkeNFFg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Jx4Wm5Ab1ZHGo0xChYRjIktwQWgHsuyWXDgDQD2zTvczKrbzk4OdxC0qV/1I1AH3llftaiMn/SrBn1BOKKJSwy8bce+8t+ENBZsqdSSgY3tqap5XUDwSoEyRZNF6zN9LlHPWKiMBW3gELWDI8p/XvkHI8UfL3UFdFChEcMBjxWc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=TKL4Wsjd; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="TKL4Wsjd" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 26A7F2C3A; Tue, 28 Apr 2026 06:04:34 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 7A0CE3F62B; Tue, 28 Apr 2026 06:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1777381479; bh=uAgjSu2NegFUXZBzIZbFe/q82XldYP83Lc5mWkeNFFg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TKL4Wsjd0LPFTovWw0fHRIA/whRz9vJI85/xGHyIvpdBbXK/yMspgc1jN0ERFi95j NSdMusCDFioAE497KuUElM8sUSpHotKIWCjKXoOpLYsEl32qEaZZ1IKb0G29I/Ie4M 3UVZQo8eZfiY0WftuRZKok1ppdlCgWDDnK7IRFYo= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v5 3/7] fs/resctrl: Disallow the software controller when MBM counters are assignable Date: Tue, 28 Apr 2026 14:04:18 +0100 Message-ID: <20260428130422.2287302-4-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260428130422.2287302-1-ben.horgan@arm.com> References: <20260428130422.2287302-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- Changes since v4: Remove "for each MBA control" from commit message Update last_cmd_status message --- fs/resctrl/rdtgroup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index b382a348dd79..be84bb210e3a 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -2530,7 +2530,8 @@ static bool supports_mba_mbps(void) return (resctrl_is_mbm_enabled() && r->alloc_capable && is_mba_linear() && - r->ctrl_scope == rmbm->mon_scope); + r->ctrl_scope == rmbm->mon_scope && + !rmbm->mon.mbm_cntr_assignable); } /* @@ -2945,7 +2946,7 @@ static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param) ctx->enable_cdpl2 = true; return 0; case Opt_mba_mbps: - msg = "mba_MBps requires MBM and linear scale MBA at L3 scope"; + msg = "mba_MBps requires MBM (mbm_event mode not supported) and linear scale MBA at L3 scope"; if (!supports_mba_mbps()) return invalfc(fc, msg); ctx->enable_mba_mbps = true; -- 2.43.0