From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4DAB2C48260 for ; Fri, 16 Feb 2024 16:29:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iaSTWUjQPmPs1qw1pkGUTYnBYBggOcIT2iwkmgUxKec=; b=gY2qvcnzK2Yhyp ea1w1nWZRKVpymkOa+u7Ox2Bqnw8c2dt1Cu3WEGkLopzDkgqYpLpS9On1dtyPx80CRqBYmCWHnPNF gojxGNvnb19JxQHHKWfmNHHfYWAeHwpB0yVQp+frK0y31+XjwfHPbAuNZzBSnl3qZ0yXjoN0OJFCO hYlqbKVMjnCscP2UjVNIPm5DtHjs0wem4ybibhLN2LbXaupn23ykIhsTeY0Z0iQjmPtFIyepQobjb KCtWheUqI9UzoawOynf8PD1TD+Eqpdt+v65SLO7ZMPfO9qBcx00C7sA5pKed8oQFdYK9gA3iobj/0 IU/hdUoseUbNpzg6VaBg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rb159-00000002zbi-3hGu; Fri, 16 Feb 2024 16:28:59 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rb157-00000002zXx-0LnN for linux-arm-kernel@lists.infradead.org; Fri, 16 Feb 2024 16:28:58 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D8DECCE2676; Fri, 16 Feb 2024 16:28:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36F7FC433C7; Fri, 16 Feb 2024 16:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708100934; bh=bLayoZaZJLZiF5BMJqBebQLCc+RBwyhci3ZXz7tlJMY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=krob6DhGMHFi1yO0jo5VUTbEo0bOL7nK+lnOcMUcxZCCEvNFnktE8Ik+Vv19iMdwV xrtviPpTD/7N+XnLu8Ds2ujzxszL1tRgQviMaufpHWGoNJkrGXhW+MATA5OHsepKEP YllORJMXxrpXwrgTDbLCZWMBA4gV82a1FA82gN9ggJRiMeJg+yT+r/m2T9vlzL7o13 V+EAps5cCqhgF+MFwd1P6FtWjqePxRDbecuixlPABVczSzme1Yot66/qBB3faMhuK3 xZj4zg20BKtSgS5XBRK/KoUYP/7mz9FHNe0ahFw11NycFL+COgiKNb0z4hqfOCGw35 4lMcJs6rwCwRg== Date: Fri, 16 Feb 2024 16:28:47 +0000 From: Will Deacon To: Robin Murphy Cc: Jason Gunthorpe , iommu@lists.linux.dev, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Lu Baolu , Jean-Philippe Brucker , Joerg Roedel , Moritz Fischer , Moritz Fischer , Michael Shavit , Nicolin Chen , patches@lists.linux.dev, Shameer Kolothum , Mostafa Saleh , Zhangfei Gao Subject: Re: [PATCH v5 01/17] iommu/arm-smmu-v3: Make STE programming independent of the callers Message-ID: <20240216162847.GA2292@willie-the-truck> References: <0-v5-cd1be8dd9c71+3fa-smmuv3_newapi_p1_jgg@nvidia.com> <1-v5-cd1be8dd9c71+3fa-smmuv3_newapi_p1_jgg@nvidia.com> <20240215134952.GA690@willie-the-truck> <20240215160135.GL1088888@nvidia.com> <02fac0ab-07ac-448e-ae4e-26788ed4fce9@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240216_082857_505584_2CE89EC4 X-CRM114-Status: GOOD ( 22.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 15, 2024 at 08:11:38PM +0000, Robin Murphy wrote: > On 2024-02-15 6:42 pm, Robin Murphy wrote: > [...] > > > > > +static void arm_smmu_get_ste_used(const __le64 *ent, __le64 > > > > > *used_bits) > > > > > =A0 { > > > > > +=A0=A0=A0 unsigned int cfg =3D FIELD_GET(STRTAB_STE_0_CFG, > > > > > le64_to_cpu(ent[0])); > > > > > + > > > > > +=A0=A0=A0 used_bits[0] =3D cpu_to_le64(STRTAB_STE_0_V); > > > > > +=A0=A0=A0 if (!(ent[0] & cpu_to_le64(STRTAB_STE_0_V))) > > > > > +=A0=A0=A0=A0=A0=A0=A0 return; > > > > > + > > > > > +=A0=A0=A0 /* > > > > > +=A0=A0=A0=A0 * See 13.5 Summary of attribute/permission > > > > > configuration fields for the > > > > > +=A0=A0=A0=A0 * SHCFG behavior. It is only used for BYPASS, > > > > > including S1DSS BYPASS, > > > > > +=A0=A0=A0=A0 * and S2 only. > > > > > +=A0=A0=A0=A0 */ > > > > > +=A0=A0=A0 if (cfg =3D=3D STRTAB_STE_0_CFG_BYPASS || > > > > > +=A0=A0=A0=A0=A0=A0=A0 cfg =3D=3D STRTAB_STE_0_CFG_S2_TRANS || > > > > > +=A0=A0=A0=A0=A0=A0=A0 (cfg =3D=3D STRTAB_STE_0_CFG_S1_TRANS && > > > > > +=A0=A0=A0=A0=A0=A0=A0=A0 FIELD_GET(STRTAB_STE_1_S1DSS, le64_to_c= pu(ent[1])) =3D=3D > > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 STRTAB_STE_1_S1DSS_BYPASS)) > > > > > +=A0=A0=A0=A0=A0=A0=A0 used_bits[1] |=3D cpu_to_le64(STRTAB_STE_1= _SHCFG); > > > > = > > > > Huh, SHCFG is really getting in the way here, isn't it? > > > = > > > I wouldn't say that.. It is just a complicated bit of the spec. One of > > > the things we recently did was to audit all the cache settings and, at > > > least, we then realized that SHCFG was being subtly used by S2 as > > > well.. > > = > > Yeah, that really shouldn't be subtle; incoming attributes are replaced > > by S1 translation, thus they are relevant to not-S1 configs. > = > That said, in this specific case I don't understand why we're worrying ab= out > SHCFG here at all - we're never going to make use of any value other than > "use incoming" because we can't rely on it being implemented in the first > place, and even if it is, we really don't want to start getting into the > forced-coherency notion that the DMA layer can'#t understand and devicetr= ee > can't describe. Yup, that's exactly what I'm thinking. We currently set it to NSH when translation is enabled, so that the stage-2 shareability is effectively an override. However, the device is either coherent, or it isn't, and so we should just leave this always set to "use incoming" in my opinion, which means we no longer need to care about qword 1 for the bypass case. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel