On Tue, Jan 14, 2020 at 12:42:47PM +0000, Will Deacon wrote: > On Thu, Dec 19, 2019 at 05:30:29PM +0100, Jean-Philippe Brucker wrote: > > Second-level context descriptor tables will be allocated lazily in > > arm_smmu_write_ctx_desc(). Help with handling allocation failure by > > moving the CD write into arm_smmu_domain_finalise_s1(). > > > > Reviewed-by: Eric Auger <eric.auger@xxxxxxxxxx> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx> > > --- > > drivers/iommu/arm-smmu-v3.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c > > index e147087198ef..b825a5639afc 100644 > > --- a/drivers/iommu/arm-smmu-v3.c > > +++ b/drivers/iommu/arm-smmu-v3.c > > @@ -2301,8 +2301,15 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain, > > cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0]; > > cfg->cd.tcr = pgtbl_cfg->arm_lpae_s1_cfg.tcr; > > cfg->cd.mair = pgtbl_cfg->arm_lpae_s1_cfg.mair; > > + > > + ret = arm_smmu_write_ctx_desc(smmu_domain, 0, &cfg->cd); > > Hmm. This ends up calling arm_smmu_sync_cd() but I think that happens before > we've added the master to the devices list of the domain. Does that mean we > miss the new SSID during the invalidation? Yes, the arm_smmu_sync_cd() isn't useful in this case, it's only needed when the STE is live and arm_smmu_write_ctx_desc() is called for a ssid!=0. On this path, the CD cache is invalidated by a CFGI_STE executed later, when arm_smmu_attach_dev() installs the STE. I didn't want to add a special case that avoids the sync when ssid==0 in because a spurious sync probably doesn't impact performance here and arm_smmu_write_ctx_desc() is quite fiddly already. Thanks, Jean
