Hi Fenghua, On Thu, 25 Feb 2021 22:17:11 +0000, Fenghua Yu <fenghua.yu@xxxxxxxxx> wrote: > Hi, Jean, > > On Wed, Feb 24, 2021 at 11:19:27AM +0100, Jean-Philippe Brucker wrote: > > Hi Fenghua, > > > > [Trimmed the Cc list] > > > > On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote: > > > When a new mm is created, its PASID should be cleared, i.e. the PASID > > > is initialized to its init state 0 on both ARM and X86. > > > > I just noticed this patch was dropped in v7, and am wondering whether we > > could still upstream it. Does x86 need a child with a new address space > > (!CLONE_VM) to inherit the PASID of the parent? That doesn't make much > > sense with regard to IOMMU structures - same PASID indexing multiple > > PGDs? > > You are right: x86 should clear mm->pasid when a new mm is created. > This patch somehow is losted:( > > > > > Currently iommu_sva_alloc_pasid() assumes mm->pasid is always > > initialized to 0 and fails on forked tasks. I'm trying to figure out > > how to fix this. Could we clear the pasid on fork or does it break the > > x86 model? > > x86 calls ioasid_alloc() instead of iommu_sva_alloc_pasid(). So We should consolidate at some point, there is no need to store pasid in two places. > functionality is not a problem without this patch on x86. But I think I feel the reason that x86 doesn't care is that mm->pasid is not used unless bind_mm is called. For the fork children even mm->pasid is non-zero, it has no effect since it is not loaded onto MSRs. Perhaps you could also add a check or WARN_ON(!mm->pasid) in load_pasid()? > we do need to have this patch in the kernel because PASID is per addr > space and two addr spaces shouldn't have the same PASID. > Agreed. > Who will accept this patch? > > Thanks. > > -Fenghua Thanks, Jacob
