linux-kernel - Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

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] [day] [month] [year] [list]

Message-ID: <ccedea22-5a90-48c7-8feb-a6f9da6e931a@arm.com>
Date: Fri, 6 Feb 2026 16:15:44 +0000
From: Ben Horgan <ben.horgan@....com>
To: wangyushan <wangyushan12@...wei.com>,
 Jonathan Cameron <jonathan.cameron@...wei.com>,
 Linus Walleij <linusw@...nel.org>
Cc: alexandre.belloni@...tlin.com, arnd@...db.de, fustini@...nel.org,
 krzk@...nel.org, linus.walleij@...aro.org, will@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 fanghao11@...wei.com, linuxarm@...wei.com, liuyonglong@...wei.com,
 prime.zeng@...ilicon.com, wangzhou1@...ilicon.com, xuwei5@...ilicon.com,
 linux-mm@...r.kernel.org, SeongJae Park <sj@...nel.org>,
 reinette.chatre@...el.com, james.morse@....com,
 Zeng Heng <zengheng4@...wei.com>, Tony Luck <tony.luck@...el.com>,
 Dave Martin <Dave.Martin@....com>, Babu Moger <babu.moger@....com>
Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

Hi Yushan,

On 2/6/26 09:54, wangyushan wrote:
> 
> On 2/5/2026 6:18 PM, Jonathan Cameron wrote:
>> On Thu, 5 Feb 2026 10:12:33 +0100
>> Linus Walleij <linusw@...nel.org> wrote:
>>
>>> But does the developer know if that hard kernel is importantest
>>> taken into account all other processes running on the system,
>>> and what happens if several processes say they have
>>> such hard kernels? Who will arbitrate? That is usually the
>>> kernels job.
>>
>> Take the closest example to this which is resctl (mpam on arm).
>> This actually has a feature that smells a bit like this.
>> Pseudo-cache locking.
>>
>> https://docs.kernel.org/filesystems/resctrl.html#cache-pseudo-locking
>>
>> My understanding is that the semantics of that don't align perfectly
>> with what we have here.  Yushan can you add more on why we didn't
>> try to fit into that scheme?  Other than the obvious bit that more
>> general upstream support for the arch definitions of MPAM is a work in
>> progress and fitting vendor specific features on top will be tricky
>> for a while at least.  The hardware here is also independent of the
>> MPAM support.
> 
> Intel cache pseudo lock requires help of IA32_PQR_ASSOC MSR, according
> to [1], that register can save necessary information for processes acquired
> cache pseudo locks, but Arm64 does not have the equivalent register.

If you have MPAM, the per exception level MPAMx_ELy registers are
somewhat equivalent. They tell you which partid and pmg identifiers the
CPU is using and IA32_PQR_ASSOC tells you the closid and rmid which are
much the same thing. Is there a difference that stops being equivalent
in this scenario?

> 
> [1]: https://www.intel.com/content/www/us/en/developer/articles/technical/cache-allocation-technology-usage-models.html
> 
[...]

Thanks,

Ben