From mboxrd@z Thu Jan 1 00:00:00 1970 From: joro@8bytes.org (Joerg Roedel) Date: Mon, 27 Mar 2017 17:33:12 +0200 Subject: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task In-Reply-To: <7386120a-2848-059f-4de0-7888a2698923@arm.com> References: <20170322154429.GE7266@8bytes.org> <20170322225320.GF7266@8bytes.org> <20170323143014.GK7266@8bytes.org> <20170323145311.GA22972@e106794-lin.localdomain> <20170323165218.GL7266@8bytes.org> <9d318e88-11af-6dab-b30e-d6b5c02443fe@arm.com> <20170324110045.GM7266@8bytes.org> <7386120a-2848-059f-4de0-7888a2698923@arm.com> Message-ID: <20170327153312.GP7266@8bytes.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Mar 24, 2017 at 07:08:47PM +0000, Jean-Philippe Brucker wrote: > On 24/03/17 11:00, Joerg Roedel wrote: > > The document you posted is an addition to the spec, so we can't rely on > > a stop marker being sent by a device when it shuts down a context. > > Current AMD GPUs don't send one, afaik. > > Fair enough, though on the SMMU side we still don't know which shutdown > model hardware vendors are more likely to choose. Devices could use the > stop marker and never wait for completion of PPRs. In that case context > shutdown would only have to make sure that PPRs are outside the PCI > network, return immediately and allow the device driver to call unbind(). Yes, on a stop-marker we should immediatly remove the PASID from the IOMMU and inform the driver. It might call unbind or do something with the device. > So to be on the safe side I think I will by default assume that PPRs are > in flight during unbind, and drain both software and hardware queue to > ensure we catch them all. The AMD driver first removes the internal mapping of the PASID to its managing data-structures, so that any follow-on faults will get rejected. Joerg