linux-kernel - Re: [PATCH RESEND v2 0/45] arm_mpam: Add KVM/arm64 and resctrl glue code

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: <20260114065149.1108631-1-zengheng4@huawei.com>
Date: Wed, 14 Jan 2026 14:51:49 +0800
From: Zeng Heng <zengheng4@...wei.com>
To: <ben.horgan@....com>, <james.morse@....com>
CC: <amitsinght@...vell.com>, <baisheng.gao@...soc.com>,
	<baolin.wang@...ux.alibaba.com>, <carl@...amperecomputing.com>,
	<catalin.marinas@....com>, <corbet@....net>, <dave.martin@....com>,
	<david@...nel.org>, <dfustini@...libre.com>, <fenghuay@...dia.com>,
	<gshan@...hat.com>, <joey.gouly@....com>, <jonathan.cameron@...wei.com>,
	<kobak@...dia.com>, <kvmarm@...ts.linux.dev>, <lcherian@...vell.com>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<maz@...nel.org>, <oupton@...nel.org>, <peternewman@...gle.com>,
	<punit.agrawal@....qualcomm.com>, <quic_jiles@...cinc.com>,
	<reinette.chatre@...el.com>, <rohit.mathew@....com>,
	<scott@...amperecomputing.com>, <sdonthineni@...dia.com>,
	<suzuki.poulose@....com>, <tan.shaopeng@...itsu.com>, <will@...nel.org>,
	<sunnanyong@...wei.com>, <zengheng4@...wei.com>
Subject: Re: [PATCH RESEND v2 0/45] arm_mpam: Add KVM/arm64 and resctrl glue code

> From: Ben Horgan <ben.horgan@....com>
> Date: Fri, 19 Dec 2025 18:11:02 +0000
> Subject: [PATCH v2 00/45] arm_mpam: Add KVM/arm64 and resctrl glue code
>
> One major departure from the previous snapshot branches referenced in the
> base driver series is that the same MPAM setting are used for kernel-space
> and user-space. That is, MPAM1_EL1 is set to the same value as MPAM0_EL1
> rather than keeping the default value. The advantages of this are that it
> is closer to the x86 model where the closid is globally applicable, all
> partids are usable from user-space and user-space can't bypass MPAM
> controls by doing the work in the kernel. However, this causes some
> priority inversion where a high priority task waits to take a mutex held by
> another whose resources are restricted by MPAM. It also adds some extra
> isb(). I would be interested in opinions/data on the policy for MPAM in
> kernel space, i.e how MPAM1_EL1 is set.

Another advantage is that, given the small size of the L2 cache,
frequent switching of MPAM configurations between kernel and user modes
can cause cache-capacity jitter, making it difficult to isolate
interference from noisy neighborhood.

However, in addition to the issues mentioned above, updating the
MPAM1_EL1 configuration also exposes interrupt handling to the MPAM
settings of the current task.

I still agree with the current modification of setting MPAM1_EL1 to the
same value as MPAM0_EL1. However, the ARM MPAM hardware supports more
flexible configuration schemes than x86 RDT and another approach is also
worth considering: Software can let a control group choose whether
kernel mode follows the user mode MPAM settings, or whether the kernel
mode configuration is delegated to the default control group, though
this may change the existing user interface.

At the LPC resctrl micro-conference, Babu also mentioned the PLZA proposal
as an attempt to address the issues raised above. Seems like no clear
interface was presented yet. Wait to see what new interface that solution
will introduce.

One last thing, please add me to the CC list for future MPAM patch series.
I'll provide timely testing on my local aarch64 environment and review
feedback. Thanks.

Best Regards,
Zeng Heng