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: <53abadfa-a429-401d-b9c8-71149b0b960d@amd.com>
Date: Thu, 29 Jan 2026 13:31:26 -0600
From: Babu Moger <bmoger@....com>
To: "Luck, Tony" <tony.luck@...el.com>, 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

Hi Tony,


On 1/29/26 12:54, Luck, Tony wrote:
> 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.

Here is the reason.

Some fields of PQR_PLZA_ASSOC must be set to the same value for all HW 
threads in the QOS domain for consistent operation (Per-QosDomain).

  The user should use the following sequence to set these values to a 
consistent state.

 1.

    Set PQR_PLZA_ASSOC[PLZA_EN]=0 for all HW threads in the QOS Domain

 2.

    Set the COS_EN, COS, RMID_EN, and RMID fields of PQR_PLZA_ASSOC to
    the desired configuration on all HW threads in the QOS Domain

 3.

    Set PQR_PLZA_ASSOC[PLZA_EN]=1 for all HW threads in the QOS Domain
    where PLZA should be enabled.

      *

        The user should perform this as a read-modify-write to avoid
        changing the value of COS_EN, COS, RMID_EN, and RMID fields of
        PQR_PLZA_ASSOC.


Basically, we have to set all the fields to consistent state to setup 
the PLZA first.   Then setup PLZA_EN bit on each thread based on current 
association.

> 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?


I really did not think of optimization here. Mostly followed the spec.


>
> 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]
>