From: Ben Horgan <ben.horgan@arm.com>
To: Zeng Heng <zengheng4@huawei.com>,
james.morse@arm.com, fenghuay@nvidia.com,
reinette.chatre@intel.com
Cc: wangkefeng.wang@huawei.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/mpam: Support partial-core boot for MPAM
Date: Thu, 29 Jan 2026 10:11:44 +0000 [thread overview]
Message-ID: <c960a8de-5f8a-42f9-8ea4-29a853bd950b@arm.com> (raw)
In-Reply-To: <20260107031336.3599175-1-zengheng4@huawei.com>
Hi Zeng,
I think I've just managed to whitelist your email address. So, all being
well I'll get your emails in my inbox.
On 1/7/26 03:13, Zeng Heng wrote:
> Some MPAM MSCs (like L2 MSC) shares the same power domain with its
> associated CPUs. Therefore, in scenarios where only partial cores power
> up, the MSCs belonging to the un-powered cores don't need and should not
> be accessed, otherwise bus-access fault would occur.
The MPAM driver intentionally to waits until all MSCs have been
discovered before allowing MPAM to be used so that it can check the
properties of all the MSC and determine the configuration based on full
knowledge. Once a CPU affine with each MSC has been enabled then MPAM
will be enabled and usable.
Suppose we weren't to access all MSCs in an asymmetric configuration.
E.g. if different L2 had different lengths of cache portion bit maps and
MPAM was enabled with only the CPUs with the same L2 then the driver
wouldn't know and we'd end up with a bad configuration which would
become a problem when the other CPUs are eventually turned on.
Hence, I think we should retain the restriction that MPAM is only
enabled once all MSC are probed. Is this a particularly onerous
resctriction for you?
>
> In such non-full core boot scenarios, the MSCs corresponding to offline
> CPUs should skip. If the MSC's accessibility mask doesn't contain any
> online CPU, this MSC remains uninitialized.
>
> During initialization of class->props, skip any MSC that is not powered
> up, so that ensure the class->props member unaffected from uninitialized
> vmsc->props in mpam_enable_init_class_features() and
> mpam_enable_merge_vmsc_features().
>
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
> drivers/resctrl/mpam_devices.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 0b5b158e1aaf..488ad2e40f66 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -2134,10 +2134,12 @@ static void mpam_enable_init_class_features(struct mpam_class *class)
> struct mpam_vmsc *vmsc;
> struct mpam_component *comp;
>
> - comp = list_first_entry(&class->components,
> - struct mpam_component, class_list);
> - vmsc = list_first_entry(&comp->vmsc,
> - struct mpam_vmsc, comp_list);
> + list_for_each_entry(comp, &class->components, class_list) {
> + list_for_each_entry(vmsc, &comp->vmsc, comp_list) {
> + if (vmsc->msc->probed)
> + break;
> + }
> + }
>
> class->props = vmsc->props;
> }
> @@ -2149,6 +2151,8 @@ static void mpam_enable_merge_vmsc_features(struct mpam_component *comp)
> struct mpam_class *class = comp->class;
>
> list_for_each_entry(vmsc, &comp->vmsc, comp_list) {
> + if (!vmsc->msc->probed)
> + continue;
> list_for_each_entry(ris, &vmsc->ris, vmsc_list) {
> __vmsc_props_mismatch(vmsc, ris);
> class->nrdy_usec = max(class->nrdy_usec,
> @@ -2620,6 +2624,7 @@ void mpam_disable(struct work_struct *ignored)
> */
> void mpam_enable(struct work_struct *work)
> {
> + cpumask_t mask;
> static atomic_t once;
> struct mpam_msc *msc;
> bool all_devices_probed = true;
> @@ -2629,8 +2634,11 @@ void mpam_enable(struct work_struct *work)
> list_for_each_entry_srcu(msc, &mpam_all_msc, all_msc_list,
> srcu_read_lock_held(&mpam_srcu)) {
> mutex_lock(&msc->probe_lock);
> - if (!msc->probed)
> - all_devices_probed = false;
> + if (!msc->probed) {
> + cpumask_and(&mask, &msc->accessibility, cpu_online_mask);
> + if (!cpumask_empty(&mask))
> + all_devices_probed = false;
> + }
> mutex_unlock(&msc->probe_lock);
>
> if (!all_devices_probed)
Thanks,
Ben
next prev parent reply other threads:[~2026-01-29 10:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 3:13 Zeng Heng
2026-01-29 10:11 ` Ben Horgan [this message]
2026-02-02 8:41 ` Zeng Heng
2026-02-02 9:16 ` Zeng Heng
2026-02-02 11:34 ` Ben Horgan
2026-02-02 12:46 ` Zeng Heng
2026-02-03 9:22 ` Zeng Heng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c960a8de-5f8a-42f9-8ea4-29a853bd950b@arm.com \
--to=ben.horgan@arm.com \
--cc=fenghuay@nvidia.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=wangkefeng.wang@huawei.com \
--cc=zengheng4@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®