linux-kernel - RE: [PATCH 2/2] x86/resctrl: Fix memory bandwidth counter width for Hygon

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: <SJ1PR11MB60831BBA388CDD191E68AD17FCA2A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 8 Dec 2025 16:52:42 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Xiaochen Shen <shenxiaochen@...n-hieco.net>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "bp@...en8.de" <bp@...en8.de>,
	"fenghuay@...dia.com" <fenghuay@...dia.com>
CC: "babu.moger@....com" <babu.moger@....com>, "james.morse@....com"
	<james.morse@....com>, "Dave.Martin@....com" <Dave.Martin@....com>,
	"x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] x86/resctrl: Fix memory bandwidth counter width for
 Hygon

>> Question: What is the value of "hw_res->mon_scale" on a Hygon system?
>
> I have double confirmed with Hygon hardware architect, in the testing Hygon system:
> hw_res->mon_scale: 64
> hw_res->mbm_width: 32
>
> Here is a rough calculation for the theoretical max bandwidth by the hardware counter:
> (1) 32-bits width and mon_scale is 64:
> 2 ^32 * 64 = 2 ^38 = 256 (B/s)
> 
> (2) 24-bits width and mon_scale is 64 (this is highly likely to cause overflow):
> 2 ^24 * 64 = 2 ^30 = 1G (B/s)

I see. Hygon has a much finer grained mon_scale than Intel (e.g. Icelake sets
mon_scale to 72KB). So a 24-bit counter will wrap easily for Hygon, but not for
Intel. The large values you saw must be from where the latest value read from the
MSR is just below the previous value. So resctrl reports chunks ~= 2^24.

Perhaps many of the reported values are wrong because the counter might wrap
24-bits multiple times in 1 second.

The fix to use the full 32-bits is correct and is resolving the problem you saw.

-Tony