From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 F341437B030 for ; Tue, 16 Jun 2026 19:51:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781639513; cv=none; b=ht+QvQGMz1uJptvwM7B9bCTdvqFr8CUBP2E3Ml84g7RtZZnm9L/Lh7InGDZ9ZQbVsseQy4075BrlLh09W98s9JsH9eAWr2jGW5uBV4ho8pDQbKGJ3kjV8yUxZCo2zt9M9C3uieFSnV+PIUXiHXuivi0a5HEyhz2E2C9epITklHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781639513; c=relaxed/simple; bh=DnPGynuAcDBjqgYuYiqIJ/6gosF6RXzkPZWMPRbrPjE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=l/DURATmPwft07S2YFcuVPYTlKQwkwFwcK2scJymoeogI3zqJpbwTV5fz9eh+kWQdtiao6Yd7Fv23Nj2iFrnMsICTYNM9xYFSvzaiCmMgJpoFSUKKjkuCMta7Q1+7QsH1CpIGuOZLKiGWCJBGDSnkX29CtS9pZ3rYM42iQl120A= 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=i8zsKqqX; arc=none smtp.client-ip=209.85.221.44 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="i8zsKqqX" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-4600ddc4017so3767060f8f.0 for ; Tue, 16 Jun 2026 12:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781639510; x=1782244310; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=oopXsR4ZloQpsMUe2KpHNKd/hTq06Y8sLkgS8GBE8k8=; b=i8zsKqqXG5UcUDfBe/NEksA+d8zBfvVlETbzODwf/hKqvznvVzc711xuHTqWDK+q1V EwLH/25mxeCVlIogEMmyrdOikLfOdmV0co6zJfW0m44qicyV6Vd2yQcNumGATNRo/rME mvo4ScnZ8nod7IQ4g8q/2veAaBfKzZbk4prjgLXhrwnfNVv01lUBq6FlM+vI0q7PU188 XfQa8G/meH8fVZtkXhlTw4T+2NP1YCbDT5OgYm+TNLfp3nHzgMwYVv1d/9MmmGikwJb7 CVWXcE2mzfkBsDYvfIDO5wUqLOdGVPxpv+Zb92TwPwAQHN6jx4O58ozJ4iXWnVs0Flyr r7hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781639510; x=1782244310; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oopXsR4ZloQpsMUe2KpHNKd/hTq06Y8sLkgS8GBE8k8=; b=gEIvmxFLCMsMnDFh+1dgUrgfCTwP0it4//rEu+vZy15zFdK4rRv6Dbk4KPzZ2e/Lw7 buOKl2j2euiKFG8VUF329VIpQ+Uek83Ge4i5FCpbsgk275C/opLkfp2X+61iESBuD86F 08y7Ig6DD4Hrvhgg1ZBOrz0FfluVMwYbn18u0JSkHFnESVMNVg+UjEvGomB/WeDX9PIw ObVNcAoRHp1wHWjT/ATU7b9SBO5U7YpLZxlYccwQIITZTXlz9rhKZF6KamoTcSm6HFuk sAUd9nxHLXh60JVuVWsk26SwKKV+jtAJLxtE26Ml4/RnkAyGWIyuNXfX+etdZxZxKYJZ P96w== X-Forwarded-Encrypted: i=1; AFNElJ9RNXQ4+zUgg78nqwdzPC8W84l+ICiFPq4HkxvXRsQ2PzePPszPykfqi1kv/O30Kz/r+K9f+IUs3z99nMg=@vger.kernel.org X-Gm-Message-State: AOJu0YxXw0wbEexH7rdh64sc1eGgvx6nRFWCJOoM0EE5zoUxBttN0Uzc Vd+3AWA5AJ/1CiwXNExFwePVJE0rdWIeKgr3nGQF3+aL+Lko1gfzKzAm X-Gm-Gg: Acq92OHuXOfK675kdKFvQ7FyAwFIgnqpXBG7kfL+1WTnguyHDOBpxTxswk3hHzmi4yW ujl8+hPZgi0105k43SVw/slXD6kzFoAGnlY4vB4RYpNz5FUU5c2IH+E1qkDl0JvI/p06DHuFy4j Ag2912QYtiy3/vjjKU0Qtxz9kyiDoz0jPEtmuuBUHMILJbFuNxuZ82QI/L2fbYV+STGXFSYXIbc b9QKxjKoW+/Ske2g2/CoJOu2YCANs2Mmisp1MOHkJhfBL4am6cRjjrJhhCw9vieTjLNotA2QpRp 4EfC9nnVr9ZtMWJYfgnVSVQGw3IziGTJ9nM+eNxwMPB+N2lIE1EfQYIDM7FbcS5aHgBRgxx/2OY p0nj7GqzSSJUHPO0JMP3c5XxVnZMqMMRWSxTnxVsf6F4bGsRWtPIC1mpXoLhmQrNPUpyBVs4PhA lnXiS1pJaVCViylqBO+6VHBTMfXKrNr1xNsmnzwIfPVp8lb8AD0ZqHIUxPvNUY X-Received: by 2002:a5d:6d44:0:b0:460:3234:293f with SMTP id ffacd0b85a97d-4623983b959mr1183937f8f.42.1781639510142; Tue, 16 Jun 2026 12:51:50 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4619a041986sm22952948f8f.23.2026.06.16.12.51.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 12:51:49 -0700 (PDT) Date: Tue, 16 Jun 2026 20:51:47 +0100 From: David Laight To: Guo Ren Cc: zhangzhanpeng.jasper@bytedance.com, alex@ghiti.fr, aou@eecs.berkeley.edu, cuiyunhui@bytedance.com, iommu@lists.linux.dev, joro@8bytes.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, luxu.kernel@bytedance.com, palmer@dabbelt.com, pjw@kernel.org, robin.murphy@arm.com, tjeznach@rivosinc.com, will@kernel.org, yuanzhu@bytedance.com Subject: Re: [PATCH v1] iommu/riscv: Support 32-bit register accesses Message-ID: <20260616205147.6aa7df98@pumpkin> In-Reply-To: References: <20260615064855.90316-1-zhangzhanpeng.jasper@bytedance.com> <20260615123821.373248-1-guoren@kernel.org> <20260616113651.1048a19a@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: quoted-printable On Tue, 16 Jun 2026 23:47:05 +0800 Guo Ren wrote: > On Tue, Jun 16, 2026 at 6:36=E2=80=AFPM David Laight > wrote: > > > > On Mon, 15 Jun 2026 12:38:17 +0000 > > Guo Ren wrote: > > =20 > > > Hi Zhanpeng Zhang, =20 > > .. =20 > > > 3. Only performance-monitoring counters require 64-bit IO access or t= he > > > high-low-high do-while retry strategy. For ordinary status and control > > > MMIO registers, a single read is sufficient. =20 > > > > Actually this sequence should be enough for a counter: > > hi =3D read_hi(); > > lo =3D read_lo(); > > if (hi !=3D read_hi()) { > > // Pick a value that happened while doing the reads. > > hi++; > > lo =3D 0; > > } =20 > This is not a free optimization =E2=80=94 it does not preserve the same > semantics as an atomic 64-bit read. There are at least two correctness > issues: >=20 > 1. Loss of precision: If hi changed during the read, setting lo =3D 0 > discards the actual lo value. The correct approach is to re-read lo > after detecting the change, not fabricate a value. >=20 > 2. Multiple overflows: This assumes at most one overflow occurs > between reads. If two overflows happen (e.g., due to interrupt > injection), hi++ will produce an incorrect result, silently corrupting > the counter value. >=20 > Negligible benefit: hi changing between reads is an extremely rare > event. Optimizing away the retry loop for such a rare case provides no > meaningful performance gain. And if hi never stabilizes, that > indicates a hardware failure =E2=80=94 in which case hanging in the retry= loop > is actually the more appropriate behavior, as it makes the failure > visible rather than silently producing garbage values. >=20 > The high-low-high do-while retry strategy exists precisely to handle > these cases correctly. I don't think this proposed sequence is a valid > replacement. >=20 The point is that if the value is an incrementing counter (of some form) then the value is stale by the time the reading sequence completes. So all the code can be assumed to do is return a value the counter had sometime between when the code started and when it finished. If hi changes then hi+1:0 must have happened while the code was running so it is a safe return value. It is likely that the reads are also much slower than memory reads. If hi changes relatively infrequently (compared to the number of reads) it may be worth saving the previously read value and avoiding the second read of hi if it is the same as the previous read hi and lo has got larger. David