linux-kernel - Re: [RFC PATCH 13/36] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate

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: <aJTng8R9eJmGR6/W@x1>
Date: Thu, 7 Aug 2025 10:50:59 -0700
From: Drew Fustini <fustini@...nel.org>
To: James Morse <james.morse@....com>
Cc: Catalin Marinas <catalin.marinas@....com>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, Rob Herring <robh@...nel.org>,
	Ben Horgan <ben.horgan@....com>,
	Rohit Mathew <rohit.mathew@....com>,
	Shanker Donthineni <sdonthineni@...dia.com>,
	Zeng Heng <zengheng4@...wei.com>,
	Lecopzer Chen <lecopzerc@...dia.com>,
	Carl Worth <carl@...amperecomputing.com>,
	shameerali.kolothum.thodi@...wei.com,
	D Scott Phillips OS <scott@...amperecomputing.com>,
	lcherian@...vell.com, bobo.shaobowang@...wei.com,
	tan.shaopeng@...itsu.com, baolin.wang@...ux.alibaba.com,
	Jamie Iles <quic_jiles@...cinc.com>,
	Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
	dfustini@...libre.com, amitsinght@...vell.com,
	David Hildenbrand <david@...hat.com>,
	Rex Nie <rex.nie@...uarmicro.com>,
	Dave Martin <dave.martin@....com>, Koba Ko <kobak@...dia.com>
Subject: Re: [RFC PATCH 13/36] arm_mpam: Add probe/remove for mpam msc driver
 and kbuild boiler plate

On Wed, Aug 06, 2025 at 07:04:09PM +0100, James Morse wrote:
> Hi Catalin,
> 
> On 24/07/2025 13:09, Catalin Marinas wrote:
> > On Fri, Jul 11, 2025 at 06:36:25PM +0000, James Morse wrote:
> >> Probing MPAM is convoluted. MSCs that are integrated with a CPU may
> >> only be accessible from those CPUs, and they may not be online.
> >> Touching the hardware early is pointless as MPAM can't be used until
> >> the system-wide common values for num_partid and num_pmg have been
> >> discovered.
> >>
> >> Start with driver probe/remove and mapping the MSC.
> 
> >>  arch/arm64/Kconfig                          |   1 +
> >>  drivers/platform/arm64/Kconfig              |   1 +
> >>  drivers/platform/arm64/Makefile             |   1 +
> >>  drivers/platform/arm64/mpam/Kconfig         |  10 +
> >>  drivers/platform/arm64/mpam/Makefile        |   4 +
> >>  drivers/platform/arm64/mpam/mpam_devices.c  | 336 ++++++++++++++++++++
> >>  drivers/platform/arm64/mpam/mpam_internal.h |  62 ++++
> >>  7 files changed, 415 insertions(+)
> >>  create mode 100644 drivers/platform/arm64/mpam/Kconfig
> >>  create mode 100644 drivers/platform/arm64/mpam/Makefile
> >>  create mode 100644 drivers/platform/arm64/mpam/mpam_devices.c
> >>  create mode 100644 drivers/platform/arm64/mpam/mpam_internal.h
> 
> > Bikeshedding: why not drivers/resctrl to match fs/resctrl? We wouldn't
> > need the previous patch either to move the arm64 platform drivers.
> 
> Initially because I don't see any other architecture having an MMIO interface to this
> stuff, and didn't want a 'top level' driver directory for a single driver. But, re-reading
> RISC-Vs CBQRI[0] it turns out that theirs is memory mapped...

Yeah, all the cpus (e.g. harts) can access all the registers of the QoS
controllers per the CBQRI spec [1].

The memory map for the example SoC in the proof-of-concept [2]:

  Base addr  Size
  0x4820000  4KB  Cluster 0 L2 cache controller
  0x4821000  4KB  Cluster 1 L2 cache controller
  0x4828000  4KB  Memory controller 0
  0x4829000  4KB  Memory controller 1
  0X482a000  4KB  Memory controller 2
  0X482b000  4KB  Shared LLC cache controller

> > I'm not an expert on resctrl but the MPAM code looks more like a backend
> > for the resctrl support, so it makes more sense to do as we did for
> > other drivers like irqchip, iommu.
> 
> Only because there are many irqchip or iommu. I'm not a fan of drivers/mpam, but
> drivers/resctrl would suit RISC-V too. (I'll check with Drew)

I think that is reasonable. In the proof-of-concept, I had the following
structure, but I think there is a lot of room for improvement. 

arch/riscv/kernel/qos/qos_resctrl.c
 Implementation of the register interface described in the CBQRI spec
 along with the resctrl implementation. I should probably break this up
 into separate files for the CBQRI operations and the resctrl interface.

drivers/soc/foobar/foobar_cbqri_cache.c
  DT-based driver for SoC cache controller that implements CBQRI

drivers/soc/foobar/foobar_cbqri_memory.c
  DT-based driver for SoC memory controller that implements CBQRI

With all the great upstream progress, I've been meaning to rebase the
RISC-V CBQRI support and post an RFC as its been a really long time.
There is no public silicon yet that implements CBQRI but I think the
possibility is getting closer. I've also been working on integrating
ACPI support [3] using the new RQSC table, and I've been meaning to post
an RFC for that too.

Thanks,
Drew

[1] https://github.com/riscv-non-isa/riscv-cbqri/releases/download/v1.0/riscv-cbqri.pdf
[2] https://lore.kernel.org/linux-riscv/20230419111111.477118-1-dfustini@baylibre.com/
[3] https://lf-rise.atlassian.net/wiki/spaces/HOME/pages/433291272/ACPI+RQSC+Proof+of+Concept