On Thu, Feb 27, 2020 at 05:43:51PM +0000, Jonathan Cameron wrote: > On Mon, 24 Feb 2020 19:23:42 +0100 > Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx> wrote: > > > From: Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx> > > > > To enable address space sharing with the IOMMU, introduce mm_context_get() > > and mm_context_put(), that pin down a context and ensure that it will keep > > its ASID after a rollover. Export the symbols to let the modular SMMUv3 > > driver use them. > > > > Pinning is necessary because a device constantly needs a valid ASID, > > unlike tasks that only require one when running. Without pinning, we would > > need to notify the IOMMU when we're about to use a new ASID for a task, > > and it would get complicated when a new task is assigned a shared ASID. > > Consider the following scenario with no ASID pinned: > > > > 1. Task t1 is running on CPUx with shared ASID (gen=1, asid=1) > > 2. Task t2 is scheduled on CPUx, gets ASID (1, 2) > > 3. Task tn is scheduled on CPUy, a rollover occurs, tn gets ASID (2, 1) > > We would now have to immediately generate a new ASID for t1, notify > > the IOMMU, and finally enable task tn. We are holding the lock during > > all that time, since we can't afford having another CPU trigger a > > rollover. The IOMMU issues invalidation commands that can take tens of > > milliseconds. > > > > It gets needlessly complicated. All we wanted to do was schedule task tn, > > that has no business with the IOMMU. By letting the IOMMU pin tasks when > > needed, we avoid stalling the slow path, and let the pinning fail when > > we're out of shareable ASIDs. > > > > After a rollover, the allocator expects at least one ASID to be available > > in addition to the reserved ones (one per CPU). So (NR_ASIDS - NR_CPUS - > > 1) is the maximum number of ASIDs that can be shared with the IOMMU. > > > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx> > A few more trivial points. I'll fix those, thanks Jean
