On 23/03/17 14:30, Joerg Roedel wrote: > On Thu, Mar 23, 2017 at 01:37:41PM +0000, Jean-Philippe Brucker wrote: >> On 22/03/17 22:53, Joerg Roedel wrote: >>> That can't happen, when the device driver does its job right. It has to >>> shut down the context which causes the PPR requests for the PASID on the >>> device. This includes stopping the context and waiting until all PPR >>> requests it sent are processed. >> >> By "processed", do you mean that they are committed to the IOMMU, or that >> they came back with a PRG response? > > By processed I mean the device received a response to the request, or is > at least no longer waiting for responses. > >> The driver might not be able to do the latter, since PCI defines two ways >> of shutting down a context: >> >> * Either wait for all PPR requests to come back with a PRG response, >> * Or send a Stop Marker PPR request and forget about it. > > Are you sure about the meaning of the stop-marker? Can you point me to > where it is specified? The concept is introduced in the PCI ECN that adds PASIDs to the ATS specification. I have the following link, which is probably behind a wall: https://pcisig.com/sites/default/files/specification_documents/ECN-PASID-ATS-2011-03-31.pdf A Stop Marker is a PPR with flags Read=Write=0, Last=1, targeting the PASID that is being decommissioned. In section 4.1.2, the specifications details the two device-specific ways of stopping use of a PASID, with or without a Stop Marker. When done with a Stop Marker, the function doesn't have to wait for any outstanding PPR to return, the Stop Marker serves as a PASID barrier. Thanks, Jean-Philippe > I know about a different marker, which allows a device to issue several > PPR requests and only get one response for all of them. The last request > then has that marker set. > > But I am not aware (yet) of a marker with which the device says it no > longer sends requests with this PASID. >> My intent with passing flags to unbind() was to handle the case where VFIO >> is unable to tell us whether PPRs are still being issued by the device. >> But the issue seems moot to me now that I have a better understanding, as >> there will be a detach_dev/attach_dev sequence before we start rebinding >> PASIDs, and we can simply reset the PRI interface there (I'm currently >> doing that in add_device, but I should move it.) > > VFIO should completly reset the device before it is re-used, so I don't > think we run into problems there. > > > > Joerg >
