From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Philippe Brucker Subject: Re: [PATCH 4/8] iommu/arm-smmu-v3: Add support for Substream IDs Date: Thu, 19 Sep 2019 17:01:39 +0200 Message-ID: <20190919150139.GC1013538@lophozonia> References: <20190610184714.6786-1-jean-philippe.brucker@arm.com> <20190610184714.6786-5-jean-philippe.brucker@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Auger Eric Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jean-Philippe Brucker , robin.murphy-5wv7dgnIgG8@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Mon, Jul 08, 2019 at 05:31:53PM +0200, Auger Eric wrote: > Hi Jean, > > On 6/10/19 8:47 PM, Jean-Philippe Brucker wrote: > > /* > > - * We don't need to issue any invalidation here, as we'll invalidate > > - * the STE when installing the new entry anyway. > > + * This function handles the following cases: > > + * > > + * (1) Install primary CD, for normal DMA traffic (SSID = 0). > > + * (2) Install a secondary CD, for SID+SSID traffic. > > + * (3) Update ASID of a CD. Atomically write the first 64 bits of the > > + * CD, then invalidate the old entry and mappings. > Can you explain when (3) does occur? When sharing a process context with devices (SVA), we write in that context descriptor the ASID allocated by the arch ASID allocator for that process. But that ASID might already have been allocated locally by the SMMU driver for a private context. As there is a single ASID space per SMMU for both private and shared ASIDs, we reallocated the private ASID and update it here. See https://lore.kernel.org/linux-iommu/20180511190641.23008-25-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org/ > > + * (4) Remove a secondary CD. > > */ > > - val = arm_smmu_cpu_tcr_to_cd(cfg->cd.tcr) | > > + > > + if (!cdptr) > > + return -ENOMEM; > Is that relevant? arm_smmu_get_cd_ptr() does not test ssid is within the > cfg->s1cdmax range and always return smthg != NULL AFAIU. It might return NULL with patch 5/8, when we can't allocate a 2nd-level table. I can move the check over to that patch. > > + ret = arm_smmu_write_ctx_desc(smmu_domain, 0, &smmu_domain->s1_cfg.cd); > cfg.cd Right. Thanks, Jean