From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) (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 E226D296BC8 for ; Fri, 6 Feb 2026 03:50:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770349850; cv=none; b=r53HF8iLCIyhWuN6NgWiZhIB64EXvnFgJWV92Zsz33PyAE9eXGuf0rUC7hx3LQY0OET4SS8OheM5Q03B/FIIWNZKCrybaxw/GK0zk9NsSjZuULlCEh1Pmn8cklcbmgXvk8K+s7rM0kUH2sHe5cC4X9z7nUOKMASNeJL/NdRmGDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770349850; c=relaxed/simple; bh=r+SSnBI5b37+jAMfBbpQKjTvolK8TUDdZyMLSQFt2fE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=JdQ7SSHKsxXsoGy8+E2jFKjzeQJhTcCy7stm9y1TfL2P6wzzUfGLquNgfUJSov5BNdKKZhd8wP8TYkZzbyQ3SuH+RYYep9ETpE/fYTuM1s2CBTKRJSNVkW77g1DCdJgH2FoG0IdLpxeAQFYtPVqedLR2ZfPq6c36Ru0TWLNa/Hs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UggsTugs; arc=none smtp.client-ip=209.85.214.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UggsTugs" Received: by mail-pl1-f195.google.com with SMTP id d9443c01a7336-2a8a7269547so14925135ad.0 for ; Thu, 05 Feb 2026 19:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770349849; x=1770954649; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mW/EfJpQhsdTtrBsXN3a2TdnMMqaf3m3vrLFSZ1aNSc=; b=UggsTugsgxIpoXh3LQdPkbUHiYo9z4CdXx2l29bwa1TXLFknX9WYVJ/4GBQTosfWim nXBzFEyxJah6Tx1SmJ2sEtJ2A2V3G447Ah5cQ5h+eV4yR4UeYnlUQx7f0HzG49P3rck3 lJSKONmr0IDBbfP98emjzTcm0msBLizM6QTJjR/svX8e7ME01sDPn6SBoIxpInRpf+/S iLsEUVmiatNWrZ6mSzFHMQqiYQOO4+oWfBwIyJ8mFr53Gia0nGLZpRlcPBiN0vBrQOtX JbGTKhA0QwWyIKdd1MAtM3zrgFKzxtsIxDaUPcfXrlBOjsUL3EV8GXZSI0kdJmfRDg6Y rSzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770349849; x=1770954649; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mW/EfJpQhsdTtrBsXN3a2TdnMMqaf3m3vrLFSZ1aNSc=; b=W6XgBB5foJWP1UIJ2UZoPIXHFLd+Sz6mPZqunpcQygf8e/a+9+MqEMGoiiwn2vjNyX 0fQCYV0wqcuWoSeWQS2GGN8cUvVpdOwC4Ouxnh0onkl2kNRfzCAU5qWMiEVFA/z03Qy8 bjjyRsZqw9KgDKLpfM40FvSBzJ51vnLaQr3A/XsLFv6kCVj2OH3J6xd14b04YHyuf6L0 1eIqI1xlmcjipT7GaY47fLQARedc5HdFvrdDvmeHjwaCQQ8odb3FUjQO56F9eSXh/7fe eYlAJaToPUiw8zmIhXljkOwMJdVFsWK+EpD5LHqmkx55ovaR+R5++PBKEx6/1r9pGfq4 nbVQ== X-Forwarded-Encrypted: i=1; AJvYcCXmIV07bNqI3RtiqmxnskZhClWEGImpv1TfP4Nsw2DoCuTTVbvTvz6u/3BUdOMZjAKdsNtkxH7rq0cpWfU=@vger.kernel.org X-Gm-Message-State: AOJu0YwoH/ze3Bg7cvb3cga8T/grH7rlKADtcLP07CHjlyN9Wk1Vn1Nt /8CwAfhkPmJry/zlNV0kXbVf5vUfdApymqwPdDDT9LW2upgorscWYOf7 X-Gm-Gg: AZuq6aI9G79TBgaEm0PZELF+SQcnxTjaRLCOwLDWo8n9U25Zrny6hSPlKK4/l4iOpqW Hpucz7/wGkvNhe+NmMQ9EOERPBHdEaQo5t1yvYmtXwAml6Gydc9VgltPFyrDXaXchwb1ZN1c9Dz OX1zkfSjdn+hxqUO0+ejV0XH88dUDUuPUhhHAc9kEMayc5ppeYJAPKy6UcyVhUEwFNu0NHs9bsn SOrraaifaCsQWiILYu3U4FXSCc6ce4tGf9P1gvww1e64ykoku5cK0dTwxtsAoWN5wYUZSt1fW6l goaK+QMRD4dfeElxK0PB8fmhQRS3vbn34GZR0QrAU5oEJ+mRg0OZwc3Kcb4clURw0P1QtXOU9rL /KaUZfCLm34uSXzM/066LzGDmFPg9Lfo3XUV87GCsocZCR3GYrzTYN8RjmQnwjqkEi7/nOFMOQR pH0azq/98nCYkz2YRSCdXUx6Y4Ex+4AWFL0zfzOMI= X-Received: by 2002:a17:903:11ce:b0:2a7:5ee5:ec50 with SMTP id d9443c01a7336-2a9516237f5mr17121575ad.17.1770349849276; Thu, 05 Feb 2026 19:50:49 -0800 (PST) Received: from PC-PF4KNQBS.Xheart.com ([202.46.41.82]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a951c8605fsm8915925ad.31.2026.02.05.19.50.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 19:50:48 -0800 (PST) From: "feng.zhou" To: Will Deacon , Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [QUESTION] ARM DSU PMU: 32-bit counter assumption and handling of 64-bit event counters Date: Fri, 6 Feb 2026 11:51:38 +0800 Message-ID: <20260206035138.1377-1-realsummitzhou@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Will and Mark, I have a question regarding the ARM DSU PMU driver implementation in drivers/perf/arm_dsu_pmu.c, specifically about the counter width assumptions. Current Implementation: ====================== The driver currently assumes all event counters are 32-bit wide, with only the cycle counter being 64-bit (lines 69-71): /* All event counters are 32bit, with a 64bit Cycle counter */ #define DSU_PMU_COUNTER_WIDTH(idx) \ (((idx) == DSU_PMU_IDX_CYCLE_COUNTER) ? 64 : 32) This assumption is used throughout the code for handling counter overflow and calculating deltas (e.g., line 344 in dsu_pmu_event_update). Issue Observed: =============== I've encountered overflow issues when using perf tools on newer ARM CPUs where the event counters appear to be 64-bit rather than 32-bit. The current implementation causes incorrect event counting and potential data loss due to premature overflow handling based on the 32-bit mask. Questions: ========== 1. Is the 32-bit event counter assumption based on the ARMv8 PMU specification or DSU-specific hardware documentation? 2. Are there known ARM CPU implementations where DSU event counters exceed 32 bits? If so, how should the driver handle this variation? 3. Would it be appropriate to detect the actual counter width at runtime (similar to how num_counters is probed in dsu_pmu_probe_pmu), or should this be handled through device tree / ACPI properties? 4. Should there be a mechanism to query the hardware for the actual counter width to ensure compatibility with future implementations? Thank you for your time and any insights you can provide. Best regards, Feng