On 24/03/17 11:00, Joerg Roedel wrote: > On Thu, Mar 23, 2017 at 05:03:46PM +0000, Jean-Philippe Brucker wrote: >> On 23/03/17 16:52, Joerg Roedel wrote: >>> Thanks for that, I have a closer look. Is that stopper packet visible to >>> software (e.g. is an entry created in the queue)? >> >> As far as I understand, it should be added to the queue like a normal PPR, >> and software should check the R/W/L flags combination. For SMMU at least, >> it is the same. The only difference is that when the PRI queue overflows, >> the SMMU would discard a Stop Marker instead of sending an automated >> response to the device (as it would do with others PPR that have the L >> flag.) Software shouldn't send a response to a Stop Marker either. > > 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(). 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. As an optimization, we can later add ways for device drivers or firmware to inform the IOMMU which PASID shutdown model is implemented (maybe a callback in svm_ops?), in which case we wouldn't have to flush the queue and if necessary, we can wait for a stop marker before throwing away a PASID. Thanks, Jean-Philippe > I think the best we can do is shutting down processing for this PASID > when and inform the device driver, when we receive a stop marker. An > additional, optional call-back would do the job. > > > > Joerg >
