Re: [PATCH 6/8] riscv: Enable resctrl filesystem for Ssqosid

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The CBQRI cache controllers lose their MMIO configurations (Capacity Block Masks) across system suspend, but the driver implements no mechanism to restore them on resume.
- [High] The per-CPU `CSR_SRMCFG` hardware register is not restored upon CPU wakeup from low-power states, allowing execution with an invalid RCID.
--

commit eb40435445d4659ca3c62bd3e4e35f35a4c254c5
Author: Drew Fustini <fustini@xxxxxxxxxx>

riscv: Enable resctrl filesystem for Ssqosid

This commit enables the CBQRI driver for RISC-V when the Ssqosid ISA extension
is enabled. It links the RISC-V architecture support with the generic resctrl
filesystem logic.

> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 9eb65d0eaa070..cc261de01107f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -595,6 +595,7 @@ config RISCV_ISA_SSQOSID
>  	depends on 64BIT
>  	default n
>  	select ARCH_HAS_CPU_RESCTRL
> +	select RISCV_CBQRI_DRIVER

[Severity: High]
Does enabling this driver introduce a regression in power management?

Looking at the CBQRI driver in drivers/resctrl/cbqri_capacity.c, the platform
driver cbqri_capacity_driver is registered but doesn't implement any
dev_pm_ops:

drivers/resctrl/cbqri_capacity.c:
	static struct platform_driver cbqri_capacity_driver = {
		.probe	= cbqri_capacity_probe,
		.driver = {
			.name		= "cbqri-capacity",
	...

During deep system suspend, power to the SoC cache controllers is typically
gated, causing the partitioned Capacity Block Masks (CBMs) managed in
drivers/resctrl/cbqri_devices.c to revert to default permissive values.

Since the driver lacks PM callbacks (like dev_pm_ops or syscore_ops) to
restore the software-configured state on resume, will cache partitioning
guarantees be broken across suspend/resume cycles?


[Severity: High]
Does this also introduce a regression with restoring the CPU CSR_SRMCFG
register after low-power transitions?

In arch/riscv/kernel/qos.c:riscv_srmcfg_pm_notify(), the CPU_PM_EXIT handler
invalidates the software cache by writing U32_MAX to cpu_srmcfg:

	case CPU_PM_EXIT:
	case CPU_PM_ENTER_FAILED:
		__this_cpu_write(cpu_srmcfg, U32_MAX);
		break;

However, it does not explicitly rewrite the hardware CSR_SRMCFG register
itself.

Since the Ssqosid extension leaves the CSR state implementation-defined
across low-power transitions, could the CPU resume execution with the
reset value (0)?

This would mean memory accesses are performed with an incorrect RCID until
the next context switch invokes __switch_to_srmcfg(), which would
temporarily break cache partitioning guarantees.

>  	help
>  	  Adds support for the Ssqosid ISA extension (Supervisor-mode
>  	  Quality of Service ID).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dfustini-atl-sc-cbqri-dt-v1-0-e79a7723fab0@xxxxxxxxxx?part=6