From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task Date: Fri, 24 Mar 2017 12:00:45 +0100 Message-ID: <20170324110045.GM7266@8bytes.org> References: <20170227195441.5170-1-jean-philippe.brucker@arm.com> <20170227195441.5170-25-jean-philippe.brucker@arm.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <9d318e88-11af-6dab-b30e-d6b5c02443fe-5wv7dgnIgG8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Jean-Philippe Brucker Cc: Shanker Donthineni , kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Catalin Marinas , Sinan Kaya , Will Deacon , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Harv Abdulhamid , linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bjorn Helgaas , David Woodhouse , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Nate Watterson List-Id: iommu@lists.linux-foundation.org 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. 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