Re: [PATCH v9 00/12] Introduce MMIO-based CMT access for Enhanced RDT

[Chen Yu <chen.yu@linux.dev>]

On Wed, Oct 14, 2026 at 10:56:57AM +0800, Chen Yu wrote:
> 
> V9 has gone through local sashiko review, with false positives left
> unaddressed. Also used AI to confirm each review feedback has been
> addressed by v9. The change history in the section "Changes since v8"
> in each patch is generated by AI.
>

Address sashiko.dev review feedback at
https://sashiko.dev/#/patchset/cover.1791933001.git.yu.c.chen%40intel.com

All 3 feedbacks from sashiko.dev have once been reported in the internal sashiko review.
They are false positive or expected behavior:

sashiko feedback1:

> @@ -742,6 +746,13 @@ static int resctrl_arch_online_cpu(unsigned int cpu)
>  	struct rdt_resource *r;
>  
>  	mutex_lock(&domain_list_lock);
> +	/* Refuse to online a CPU whose ERDT and CPUID L3 domain views disagree. */
> +	if (!erdt_try_bind_cpu(cpu)) {
> +		mutex_unlock(&domain_list_lock);
> +		clear_closid_rmid(cpu);
> +		return -EINVAL;
Does returning an error from resctrl_arch_online_cpu() abort the CPU hotplug
state machine, preventing the CPU from joining the system?
The commit message mentions this is an intentional tradeoff to avoid
complicating cpus_ctrl_write(). However, since ACPI ERDT is an optional
performance monitoring feature, returning -EINVAL here on systems with buggy
ACPI tables appears to permanently disable CPU cores. Could this be changed
to leave the CPU online but unbound from any resctrl domains?

response1 to sashiko:
This is expected, and it is a trade-off between “simplicity” and ”absolute correctness“:
"Leaving the CPU online but outside all resctrl domains is doable, but it would require a
change to cpus_ctrl_write() to reject CPUs that are online but not tracked by
any resctrl group. The current approach is stricter, but simpler."


sashiko feedback2:
>  
> +unsigned int resctrl_arch_round_mon_val(unsigned int val)
> +{
> +	unsigned int scale = boot_cpu_data.x86_cache_occ_scale;
> +
> +	/* h/w works in units of "boot_cpu_data.x86_cache_occ_scale" */
> +	val /= scale;
Will this divide by zero if the hardware or hypervisor reports a cache
occupancy scale of 0 via CPUID leaf 0xf sub-leaf 1 (EBX=0)?

response2 to sashiko:
This is a pre-existing issue. If the scale is zero, then this machine is unreliable,
panicking the system would be acceptable.



sashiko feedback3:
> +
> +	l3_cmt_count = readq(d->base[ERDT_MMIO_CMRC_BASE] + offset);
Could this result in an unaligned MMIO read that crashes the kernel?


response3 to sashiko:
On x86 there is no 8 bytes alignment requirement for readq address.

thanks,
Chenyu