From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 743303E00BA for ; Thu, 11 Jun 2026 11:17:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781176648; cv=none; b=V/sMsGI4dAyt8QxtvAare5zqhxPvtaRDRLZOmeTgDZ510NaxjtuG4NYwppkmwE/gTB2WGNAl9G0OWK330g+h2fcz/CC0zYflkgMRjOwB4mrisRQ7GMnGVO4s3Ok9LZ/plKvKjf8plghGLg5amoHBfSL0pf+RQn9GB9yRrVKdQPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781176648; c=relaxed/simple; bh=q/eqcGkTGXkNiYgB7wRc9m5Ch3YUu7+tlGCU2A3hHFk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fXDUJ4YRPT6Yc2LoZLmQEjSGa9+nRIepreDg/i4gi3yDIVXjK+NYuMUFQHVju15NhEH8DtEmNG8ntQGH8HINldOq1REhGnfkY71bIWqLe3Le6u+L5tSfE1iWTuZr1n7AhjyRfdKQ/BNrI2i7hAeT7d/IOcm7YERSajILzdKLTYc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Wu2w3TUU; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Wu2w3TUU" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1781176637; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=DBs33/PI1020kI8Nuj1AY4mskWywP4UDKhySQeZWmd4=; b=Wu2w3TUUMvnYkRJyDCaD60EhK9riDBjnatieawHk8SNHm3moqYrSFbZc8XFA8t/pBX5DNoGTTsXQ9nNIpsdLei5Tbq14Rlb1CbzScJ2uYJrQsF0tESbQ5OPsW6ls9xfhyqw4dMYc3j81vvzQrUP6IpYiC8ZRhl5nN2sya6FchfU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=qinyuntan@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0X4dSidL_1781176635; Received: from banye.tbsite.net(mailfrom:qinyuntan@linux.alibaba.com fp:SMTPD_---0X4dSidL_1781176635 cluster:ay36) by smtp.aliyun-inc.com; Thu, 11 Jun 2026 19:17:16 +0800 From: Qinyun Tan To: babu.moger@amd.com Cc: tony.luck@intel.com, reinette.chatre@intel.com, james.morse@arm.com, Dave.Martin@arm.com, tglx@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, feng.tang@linux.alibaba.com, xlpang@linux.alibaba.com, Qinyun Tan Subject: [PATCH 4/4] fs/resctrl: program PLZA on a CPU that comes online under a binding Date: Thu, 11 Jun 2026 19:17:06 +0800 Message-ID: <20260611111706.1981788-5-qinyuntan@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: References: 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 kernel-mode (PLZA) MSR (MSR_IA32_PQR_PLZA_ASSOC) is per-CPU and is only written when a binding is configured via info/kernel_mode or when a group's kmode_cpus mask is changed. Both paths only touch the CPUs that are online at that moment, and the CPU hotplug online callback does not reprogram it. As a result, a CPU that comes online *after* a binding is in place -- a hot-added vCPU, or a CPU that was offline at bind time -- runs with PLZA disabled even though an empty kmode_cpu_mask ("all online CPUs") or an explicit mask says it is in scope. Its CPL0 traffic then uses the default PQR_ASSOC CLOSID/RMID instead of the bound kernel-mode group, so the kernel-mode protection is silently off on that CPU while info/kernel_mode still reports the binding as active. Make resctrl_online_cpu() the single authoritative sync point: on every CPU online, idempotently drive the CPU to the state it should have under the current binding -- enable PLZA with the bound CLOSID/RMID when the CPU is in scope, otherwise explicitly clear it so stale enable bits left on a CPU that was offline while it was removed from the scope are cleared too (offline CPUs are skipped by the IPI-based reprogram paths and the MSR is not reset by a soft offline). Bail out early on platforms without kernel-mode support so the MSR is never touched there. offline needs no counterpart: a CPU's PLZA state is fully determined by this online-time sync. Signed-off-by: Qinyun Tan Reviewed-by: Xunlei Pang --- fs/resctrl/rdtgroup.c | 53 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index cef6ab75c2b57..35cc0083d1b2f 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -5336,11 +5336,64 @@ int resctrl_online_mon_domain(struct rdt_resource *r, struct rdt_domain_hdr *hdr return err; } +/* + * resctrl_kmode_online_cpu() - Sync a freshly onlined CPU to its PLZA state + * @cpu: The CPU that just came online. + * + * The kernel-mode (PLZA) MSR is per-CPU and is only written when a binding is + * configured or its kmode_cpus mask is changed; nothing reprograms it for a + * CPU that comes online afterwards. Make the online callback the single + * authoritative sync point: idempotently drive @cpu to the state it should + * have under the current binding. This both programs a CPU that is onlined + * after a binding is in place (e.g. a hot-added vCPU, or a CPU that was + * offline at bind time) and clears stale enable bits left on a CPU that was + * offline while it was removed from the scope (offline CPUs are skipped by + * the IPI-based reprogram paths and the MSR is not reset by a soft offline). + * + * Scope: an empty kmode_cpu_mask means "all online CPUs" (so @cpu is always + * included), a non-empty mask means only the CPUs explicitly listed there. + * + * Context: Caller must hold rdtgroup_mutex. Runs on @cpu during the CPU + * hotplug online callback, so the MSR write lands on the right CPU and no + * cross-CPU IPI is needed. + */ +static void resctrl_kmode_online_cpu(unsigned int cpu) +{ + struct rdtgroup *rdtgrp = resctrl_kcfg.k_rdtgrp; + u32 closid = 0, rmid = 0; + bool assign_rmid = false; + bool enable = false; + + /* Platform without kernel-mode (PLZA) support: never touch the MSR. */ + if (!(resctrl_kcfg.kmode & ~BIT(INHERIT_CTRL_AND_MON))) + return; + + /* Compute this CPU's correct state under the active binding. */ + if (resctrl_kcfg.kmode_cur != BIT(INHERIT_CTRL_AND_MON) && rdtgrp && + (cpumask_empty(&rdtgrp->kmode_cpu_mask) || + cpumask_test_cpu(cpu, &rdtgrp->kmode_cpu_mask))) { + if (rdtgrp->type == RDTMON_GROUP) { + closid = rdtgrp->mon.parent->closid; + rmid = rdtgrp->mon.rmid; + } else { + closid = rdtgrp->closid; + rmid = rdtgrp->mon.rmid; + } + assign_rmid = (resctrl_kcfg.kmode_cur == BIT(GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU)); + enable = true; + } + + /* Idempotent sync: enable when in scope, otherwise clear stale bits. */ + resctrl_arch_configure_kmode(cpumask_of(cpu), closid, rmid, assign_rmid, enable); +} + void resctrl_online_cpu(unsigned int cpu) { mutex_lock(&rdtgroup_mutex); /* The CPU is set in default rdtgroup after online. */ cpumask_set_cpu(cpu, &rdtgroup_default.cpu_mask); + /* Restore the kernel-mode (PLZA) binding on a CPU that just came online. */ + resctrl_kmode_online_cpu(cpu); mutex_unlock(&rdtgroup_mutex); } -- 2.43.7