linux-kernel - Re: [RFC PATCH 16/19] fs/resctrl: Implement rdtgroup_plza

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXus-rG1BX8QWh_G@agluck-desk3>
Date: Thu, 29 Jan 2026 10:54:50 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Babu Moger <babu.moger@....com>
CC: <corbet@....net>, <reinette.chatre@...el.com>, <Dave.Martin@....com>,
	<james.morse@....com>, <tglx@...nel.org>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
	<peterz@...radead.org>, <juri.lelli@...hat.com>,
	<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
	<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
	<vschneid@...hat.com>, <akpm@...ux-foundation.org>,
	<pawan.kumar.gupta@...ux.intel.com>, <pmladek@...e.com>,
	<feng.tang@...ux.alibaba.com>, <kees@...nel.org>, <arnd@...db.de>,
	<fvdl@...gle.com>, <lirongqing@...du.com>, <bhelgaas@...gle.com>,
	<seanjc@...gle.com>, <xin@...or.com>, <manali.shukla@....com>,
	<dapeng1.mi@...ux.intel.com>, <chang.seok.bae@...el.com>,
	<mario.limonciello@....com>, <naveen@...nel.org>,
	<elena.reshetova@...el.com>, <thomas.lendacky@....com>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<kvm@...r.kernel.org>, <peternewman@...gle.com>, <eranian@...gle.com>,
	<gautham.shenoy@....com>
Subject: Re: [RFC PATCH 16/19] fs/resctrl: Implement rdtgroup_plza_write() to
 configure PLZA in a group

On Wed, Jan 28, 2026 at 02:03:31PM -0800, Luck, Tony wrote:
> On Wed, Jan 21, 2026 at 03:12:54PM -0600, Babu Moger wrote:
> > Introduce rdtgroup_plza_write() group which enables per group control of
> > PLZA through the resctrl filesystem and ensure that enabling or disabling
> > PLZA is propagated consistently across all CPUs belonging to the group.
> > 
> > Enforce the capability checks, exclude default, pseudo-locked and CTRL_MON
> > groups with sub monitors. Also, ensure that only one group can have PLZA
> > enabled at a time.
> > 
> ...
> 
> > +static ssize_t rdtgroup_plza_write(struct kernfs_open_file *of, char *buf,
> > +				   size_t nbytes, loff_t off)
> > +{
> > +	struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3);
> > +	struct rdtgroup *rdtgrp, *prgrp;
> > +	int cpu, ret = 0;
> > +	bool enable;
> 
> ...
> 
> > +	/* Enable or disable PLZA state and update per CPU state if there is a change */
> > +	if (enable != rdtgrp->plza) {
> > +		resctrl_arch_plza_setup(r, rdtgrp->closid, rdtgrp->mon.rmid);
> 
> What is this for? If I've just created a group with no tasks, and empty
> CPU mask ... it seems that this writes the MSR_IA32_PQR_PLZA_ASSOC on
> every CPU in every domain.

I think I see now. There are THREE enable bits in your
MSR_IA32_PQR_PLZA_ASSOC.
One each for CLOSID and RMID, and an overall PLZA_EN in the high bit.

At this step you setup the CLOSID/RMID with their enable bits, but
leaving the PLZA_EN off.

Is this a subtle optimzation for the context switch? Is the WRMSR
faster if it only toggle PLZA_EN leaving all the other bits unchanged?

This might not be working as expected. The context switch code does:

		wrmsr(MSR_IA32_PQR_PLZA_ASSOC,
		      RMID_EN | state->plza_rmid,
		      (plza ? PLZA_EN : 0) | CLOSID_EN | state->plza_closid);

This doesn't just clear the PLZA_EN bit, it zeroes the high dword of the MSR.

> It also appears that marking a task as PLZA is permanent. Moving it to
> another group doesn't unmark it. Is this intentional?

Ditto assigning a CPU to the PLZA group. Once done it can't be undone
(except by turing off PLZA?).

-Tony

[More comments about this coming against patch 16]