From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-231.mta0.migadu.com [91.218.175.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 55CFA4E4308 for ; Mon, 19 Oct 2026 12:45:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.231 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792413924; cv=none; b=Zg4Hj8A/SKBlLzsaHF+7n5o9IHKICBmxvib+N44p73p80EIBLhcTeOkCyFVLlX/H6Y3QL2tfkasumSmiAutgSrGX0iBivlalcBfUm51lxjcCYN0YRUBk5heUo/pnItk3heoX2tE2uMgtG0kJPjI7RZMcIxcPKIQkxRG0K7fI518= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792413924; c=relaxed/simple; bh=ZNi+tfO1peS3KDOxghfnfHqPGcB5PU924w+Za6LB9Gc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qQ27VHgG6SQTJRvn6fde2lUB2KYbrcgQOowMsHKdAYj7TwVCezl/NGXNi0axizT1/pXV1LYq5JB2sxCDq/665VzNUQx1Mj/UgTx6s3sFIe1dK/xERg600twD9D7vAvZu6wcWurmrxeWfGxHKyGAMBsoauhCb6BZPSruW2nSjZnY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Dw8rxyPp; arc=none smtp.client-ip=91.218.175.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Dw8rxyPp" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=ZNi+tfO1peS3KDOxghfnfHqPGcB5PU924w+Za6LB9Gc=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792413914; v=1; x=1793018714; b=Dw8rxyPpe13bRCGjPJCdBQZt4lBR9O/ilA6D9J8JdH69RiLl+ZTlxevilVbp5rn0YZH65X1P 3frObRTYAwjo6NY8AZ4DcOaeNRL9WLLFRHv0coTGLT027s0+3MbMMawFZBcsp9JDGzUFRr0NL3E /kGXzBVwOBzj9+JZJXBJPYCI= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id e8a4ddf175a332fc; Mon, 19 Oct 2026 12:45:12 +0000 X-Mizu-Trace-ID: e8a4ddf175a332fc X-Migadu-Flow: FLOW_OUT Date: Mon, 19 Oct 2026 20:45:51 +0800 From: Chen Yu To: Chen Yu Cc: tony.luck@intel.com, reinette.chatre@intel.com, tglx@kernel.org, bp@alien8.de, mingo@redhat.com, dave.hansen@linux.intel.com, hpa@zytor.com, fenghuay@nvidia.com, babu.moger@amd.com, hongyu.ning@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 00/12] Introduce MMIO-based CMT access for Enhanced RDT Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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