From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8E3624477E6 for ; Tue, 28 Jul 2026 13:52:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785246725; cv=none; b=XKomWFnYj1hnou0NYnDnDabjTLTCLTTT6qD6ibzKkq1CWUvvcpjTr87JnL5dQZ45jagTeCr3rX8vvxLvvd/43Ftm0JQGLpVBfIkZ2ukCxoke+NY+3NU7OeI8Mty+qHLEAVZ3AW2ERxIwjpYp18cKC4GjL46OACXaypE+fhj1kxs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785246725; c=relaxed/simple; bh=D9tuZ7TgfiejMAziPCns6WI6Lsx4NkLm93++qTnEQug=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GNC493f89tAzkxyV/fmktCBUmSoZrAncHJVXuheg8GY31grt5ThjW7kX3/7dW6acNdhoBc3rAb/mxkGcS8CNsVhbgqmGFHOKG5h3KiscUMSb+BNfSfHUzrlM9VgpUPaTWjkIHqTz2bh5ditd3O6HD13pHUYHg5niaSQU8drCiE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=mKI0EVM5; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="mKI0EVM5" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4BEE11650; Tue, 28 Jul 2026 06:51:56 -0700 (PDT) Received: from [10.2.212.8] (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 58FCA3F763; Tue, 28 Jul 2026 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1785246720; bh=D9tuZ7TgfiejMAziPCns6WI6Lsx4NkLm93++qTnEQug=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mKI0EVM57U47HYX40a/RYiP4y1/FbV8AocLkWKYeR8Hv2YOD5KFZNQHFpefw4qDBy bzHb5nXI06UHsswZ7bwDypjx0w7SSVr7d/HsWuePrg2cGOrKUr/qm38gC4ihyc7t9/ hScu2LpzKicsr5n/shWCY6Mi7Z3Lu3JVKInTngs4= Message-ID: Date: Tue, 28 Jul 2026 14:51:58 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [PATCH] arm_mpam: Apply T241-MPAM-6 to 63-bit counters To: Shanker Donthineni , James Morse , Catalin Marinas , Will Deacon Cc: Reinette Chatre , Fenghua Yu , Shaopeng Tan , Zeng Heng , linux-kernel@vger.kernel.org References: <20260727191326.2202616-1-sdonthineni@nvidia.com> <8618c244-eadc-4226-ae5c-86b719ac5e7d@arm.com> Content-Language: en-US From: Ben Horgan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Shanker, On 7/28/26 14:42, Shanker Donthineni wrote: > Hi Ben, > > On 7/28/2026 5:48 AM, Ben Horgan wrote: >> External email: Use caution opening links or attachments >> >> >> Hi Shanker, >> >> On 7/27/26 20:13, Shanker Donthineni wrote: >>> T241-MPAM-6 causes all MBWU counter formats to count 64-byte >>> requests instead of bytes. Commit dc48eb1ff27c excluded the 63-bit >> As described in that commit message, T241-MPAM-6 does not affect LWD counters. Is there another >> canonical description of T241-MPAM-6. Otherwise, this just looks like you've discovered a new h/w >> bug :) > The original commit message for dc48eb1ff27c explicitly states that T241-MPAM-6 affects both > MSMON_MBWU and MSMON_MBWU_L: > >  "The registers MSMON_MBWU_L and MSMON_MBWU return the number of requests rather than the number >   of bytes transferred." > > LWD (when HAS_LONG=1) selects the width/format of MSMON_MBWU_L; it does not identify a separate > register outside the scope described above. Oh yes, you are right. The L_VALUE/LWD_VALUE naming is just internal to the driver. > >>> MSMON_MBWU_LWD format while scaling the shorter counters. Systems >>> selecting the preferred 63-bit counter consequently report bandwidth >>> values that are 64 times too small. >> So, the MSC with IIDR MPAM_IIDR_NVIDIA_T241 has different sizes of long bandwidth counters between >> RIS. This seems a bit unusual. Please could you share which RIS have 44 bit long counters and which >> have 63 bits. (MPAMF_MBWUMON_IDR.LWD gives this) > T241 does not implement RIS (MPAMF_IDR.HAS_RIS=0). Its L3 MSC implements a 63-bit long bandwidth > counter, as indicated by HAS_LONG=1 and LWD=1; therefore, there are no per-RIS differences in > counter width. Ok, so there are no 44 bit counters? Reviewed-by: Ben Horgan Thanks, Ben > > The mpam_feat_msmon_mbwu_63counter exclusion in dc48eb1ff27c means the workaround is not applied > to the long-counter format implemented by the T241 L3 MSC. This patch removes that exclusion and > makes the implementation consistent with the original erratum description and commit message. > >> Thanks, >> >> Ben >> >>> Apply the scale to both the sampled value and overflow correction for >>> the 63-bit format. Unsigned arithmetic retains modulo-u64 behavior >>> when the scaled counter range exceeds u64. >>> >>> Fixes: dc48eb1ff27c ("arm_mpam: Add workaround for T241-MPAM-6") >>> Link: https://lore.kernel.org/lkml/20240816131432.993859-1-sdonthineni@nvidia.com/ >>> Signed-off-by: Shanker Donthineni >>> --- >>>   drivers/resctrl/mpam_devices.c | 6 ++---- >>>   1 file changed, 2 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c >>> index 2f09f4b78bd3b..b68f5599e8dbe 100644 >>> --- a/drivers/resctrl/mpam_devices.c >>> +++ b/drivers/resctrl/mpam_devices.c >>> @@ -1196,8 +1196,7 @@ static u64 mpam_msmon_overflow_val(enum mpam_device_features type, >>>   { >>>        u64 overflow_val = __mpam_msmon_overflow_val(type); >>> >>> -     if (mpam_has_quirk(T241_MBW_COUNTER_SCALE_64, msc) && >>> -         type != mpam_feat_msmon_mbwu_63counter) >>> +     if (mpam_has_quirk(T241_MBW_COUNTER_SCALE_64, msc)) >>>                overflow_val *= 64; >>> >>>        return overflow_val; >>> @@ -1293,8 +1292,7 @@ static void __ris_msmon_read(void *arg) >>>                        now = FIELD_GET(MSMON___VALUE, now); >>>                } >>> >>> -             if (mpam_has_quirk(T241_MBW_COUNTER_SCALE_64, msc) && >>> -                 m->type != mpam_feat_msmon_mbwu_63counter) >>> +             if (mpam_has_quirk(T241_MBW_COUNTER_SCALE_64, msc)) >>>                        now *= 64; >>> >>>                if (nrdy) >