Messages in this thread | | | Date | Wed, 29 Mar 2023 14:22:50 +0800 | Subject | Re: [PATCH v2 6/8] iommu/vt-d: Implement set_dev_pasid domain op | From | Baolu Lu <> |
| |
On 3/28/23 11:40 PM, Jacob Pan wrote: > Hi Kevin, > > On Tue, 28 Mar 2023 07:47:45 +0000, "Tian, Kevin" <kevin.tian@intel.com> > wrote: > >>> From: Jacob Pan <jacob.jun.pan@linux.intel.com> >>> Sent: Tuesday, March 28, 2023 7:22 AM >>> >>> Devices that use ENQCMDS to submit work on buffers mapped by DMA API >>> must attach a PASID to the default domain of the device. In preparation >>> for this use case, this patch implements set_dev_pasid() for the >>> default_domain_ops. Besides PASID attachment, device will also be >>> attached to the domain as the result of this call if the device has not >>> been attached before. >>> >> >> I didn't get the last point. PASID attach should only have the scope >> for the pasid. RID of the device might be attached to another domain >> which shouldn't be changed by this call. > I meant if the RID context has not been set up before attaching this PASID, > this call will also set up the context, PASID dir etc. In the end, we > eliminated ordering requirement of attaching device, RID_PASID first, then > other PASIDs.
This occurs in default domain deferred attaching case.
> How about: > "If the device context has not been set up prior to this call, this will > set up the device context in addition to PASID attachment."
Best regards, baolu
| |