From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 907993B27D7 for ; Thu, 18 Jun 2026 13:36:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781789801; cv=none; b=mp7O7Z/J4G1qmE3FsvEc5EZNB7VyJkrn+MUkPDYmJ5QhI9pB5NfV8MAo3HIo5C16sjHZsAh0FVhWK258vyeLUTdT7kiA6R82o4qxU5As7Cra7ZqkQq/czD2HcjhVRH1WjIZtH6ykXovdjK/qZUf3dZcHvnchQuN7xt26qYG49EM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781789801; c=relaxed/simple; bh=NtK8KAGuOvAPqgQxA0H02Zs1LcqLCIFigx5592EZT3o=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YDGs8NJYOCYztcUeLVswSZcQI4/PtBEdnywTvFlnGuaALn/8Xot80HEsPTZXXPrXB4ZImbuoh49yopmRWU9fFN5Fy/4n4n2eQmIXuki1sP0M0RHk+/zatmi3jHnDFDuxAa/M+S/l8NNnyyAu4N81J8g+iphzc5mAMRbmOSQt23c= 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=piB+mrGY; arc=none smtp.client-ip=209.85.221.42 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="piB+mrGY" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-463b2f6fc9dso999284f8f.2 for ; Thu, 18 Jun 2026 06:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781789798; x=1782394598; 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=qavgJPHHOECEJ91w79AZ813o0Mh7WejFknktQtGHNq8=; b=piB+mrGYiE7I55NW5kCYcU5MuVxYcZK3DZhXfXqoRNUHPju8AGP1RIr35gkD3dJ4KR bDNqdbMF8Qt3yjKR1bkUdYfC4VLGOJzCtea8/xc4pNuxVehlwU0GPs/dBvytgNPMcnJ+ o+gXx7nGOeb+XemF3yFM9QwF+cZenhvzKZ4BMapALVBTFRoAEI3ocPNhvEzCoJ6CO/wr 6SzLgVItj62HPKv/BE9Ngdahdx0+iopWBJyt7JBtk4haWu9CqG0WIqfUUiQW9wjaDN/X GddQEYQOGccJgPmmAT/JTsGb8DJ05uTlYDsZVf+8L9mL3clZF4VaYSIikzGCMesVvcHm dL2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781789798; x=1782394598; 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=qavgJPHHOECEJ91w79AZ813o0Mh7WejFknktQtGHNq8=; b=nLL7bANbr6UDdexZQ93ugrj1aODmNcse7x3ZPkk5khnxnzA+cfGvT49diJj8y6M0kR yknwK+ZwTArjhdpmrfpTqfnszhpxmo4xcViTaFcwdymc3VK96tIHlhIx9LvREcOATaQp 241hLi7ungI59TFT3RupzalGhjLZUiCCP6IEN6daH+DBUVPGGJ1hqZ+OdGvtbxpNkkcM NLc4iCDsouLX6mMyZdH2gNmLIGY8Jg+fWxupq9UVmKgd3a1fh+S1wwX9vvg1aD8+NNd8 G6HXXr0YFeU2lSxo6iPWlSrC9gVsFUGh2Vx/b2XhrHVIzzzli4n6CIWw9TssBPbmFtEo RTQg== X-Forwarded-Encrypted: i=1; AFNElJ+J13B4FzbXoBzeiT+SYwim+vjqhoNw+eZgFTGQomDn+4CR2tzZLyggT3Mq7xKqwQww33vNurC+x1Ss/Oc=@vger.kernel.org X-Gm-Message-State: AOJu0YwclkDpqn25BXKcwxKcNCkYM5tTJrgzchVuZtfJW3Sbpbn1LAaV WTOtVANA8E/4MehAGieqxP3TkYG92dv2YmXXGFTt9vbjFrGV6JU60Xyu X-Gm-Gg: AfdE7cmdzuwsstddVt5omWd6OlvSkpl5HtNvZH8Ai+o2ED1uLRjCIs0dq9LfmPo3U8w LTA0DhYOgDM0U4p0Z8LUYQB2/1l8ZG/4/pRupIwq0ILFLdnP/0oPeUqWIIg46exeRT/TJ2t9cG8 Y49QHtaMR9OgYUambYKNE7K/8YxYdg5e2n0vSrsOEkjAfGHC5Ijrdeius8P3yAf/6iUFDzK5bPU TpIyYRrkWMAcAgAggSYl6WiIUaCYJYTS2mjrSoI2dZ4faoIXErR5d6qsXULPfuGJQLvVl3sb1QF XvwZTSnAsoKIrRur6pS6sPTVa8OPWrSVMsCn8VNQ474eheIlNCThmicA5x5VDfR7CTjQAbU2gKN jpHV4LjES/N3NXXDRyrG5wXaPY7CkUCfGEbz3g9KarZgNyzWSgB8EKdH/qTUC/siTEGiJO6Xpz+ E6XQ60NmFyZmwZebvlb+u9PmejkyHX49+juuY2sSkq5dG+Ksg3Gb+2ut3dn+hz X-Received: by 2002:a05:600c:4f91:b0:492:1e36:d16e with SMTP id 5b1f17b1804b1-492333f7ff3mr144524195e9.36.1781789797510; Thu, 18 Jun 2026 06:36:37 -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 5b1f17b1804b1-49230a58fddsm233967025e9.8.2026.06.18.06.36.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 06:36:37 -0700 (PDT) Date: Thu, 18 Jun 2026 14:36:34 +0100 From: David Laight To: Guo Ren Cc: Vivian Wang , 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: <20260618143634.7f3dd6c5@pumpkin> In-Reply-To: References: <20260615064855.90316-1-zhangzhanpeng.jasper@bytedance.com> <20260615123821.373248-1-guoren@kernel.org> <7c490aeb-a3d9-4fe9-81de-f9662577851d@iscas.ac.cn> 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 Thu, 18 Jun 2026 17:51:34 +0800 Guo Ren wrote: > Hi Vivian, >=20 > As noted in the RISC-V IOMMU Specification, Chapter 6: > > Whether an 8-byte access to an IOMMU register is single-copy atomic is = UNSPECIFIED, and such an access may appear, internally to the IOMMU, as if = two separate 4-byte accesses =E2=80=94 first to the high half and second to= the low half =E2=80=94 were performed. =20 >=20 > Therefore, the atomicity of 64-bit MMIO accesses is UNSPECIFIED and > not clearly defined in the current ratified RISC-V IOMMU > specification. To handle this correctly, the Linux RISC-V IOMMU driver > should fall back to 32-bit MMIO accesses when reading 64-bit registers > (e.g., performance counters). The behavior of 32-bit MMIO accesses is > more precisely defined in the RISC-V IOMMU specification. >=20 > Thus, many hardware vendors implement 32-bit MMIO (rather than 64-bit > MMIO) based on the current ratified RISC-V IOMMU specification, and > this driver does not appear to benefit from 64-bit MMIO access either. > Performance is fundamentally constrained by bus latency; assuming that > simply reducing the number of accesses will improve performance is an > oversimplification that ignores the underlying hardware > characteristics. If the bus latency is significant it is almost certainly worth using memory accesses to avoid re-reading the hi register. Something like this might work: static volatile u32 hi_prev, lo_prev; u32 hi =3D read_reg_hi(); u32 lo =3D read_reg_lo(); if (lo <=3D lo_prev || hi !=3D hi_prev) { u32 hi_tmp =3D read_reg_hi; if (hi_tmp !=3D hi) { hi =3D hi_tmp; lo =3D 0; } lo_prev =3D ~0u; hi_prev =3D hi; } lo_prev =3D lo; return (u64)hi << 32 | lo; It shouldn't need any locking but the accesses do need to be ordered. David