Re: Support SVM without PASID

[valmiki <valmikibow-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 8/1/2017 1:56 PM, Jean-Philippe Brucker wrote:
> Hi Valmiki,
>
> Sorry for the delay, I was away last week.
>
> On 22/07/17 03:05, valmiki wrote:
>> On 7/12/2017 10:18 PM, Jean-Philippe Brucker wrote:
>>> On 12/07/17 17:27, valmiki wrote:
>>>> On 7/11/2017 4:26 PM, Jean-Philippe Brucker wrote:
>>>>> Hi Valmiki,
>>>>>
>>>>> On 09/07/17 04:15, valmiki wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> In SMMUv3 architecture document i see "PASIDs are optional,
>>>>>>>> configurable, and of a size determined by the minimum
>>>>>>>> of the endpoint".
>>>>>>>>
>>>>>>>> So if PASID's are optional and not supported by PCIe end point, how
>>>>>>>> SVM
>>>>>>>> can be achieved ?
>>>>>>>
>>>>>>> It cannot be inferred from that statement that PASID support is not
>>>>>>> required for SVM.  AIUI, SVM is a software feature enabled by numerous
>>>>>>> "optional" hardware features, including PASID.  Features that are
>>>>>>> optional per the hardware specification may be required for specific
>>>>>>> software features.  Thanks,
>>>>>>>
>>>>>> Thanks for the information Alex. Suppose if an End point doesn't support
>>>>>> PASID, is it still possible to achieve SVM ?
>>>>>> Are there any such features in SMMUv3 with which we can achieve it ?
>>>>>
>>>>> Not really, we don't plan to share the non-PASID context with a process.
>>>>>
>>>>> In theory you could achieve something resembling SVM by assigning the
>>>>> entire endpoint to userspace using VFIO, then use ATS+PRI capabilities
>>>>> with a bind ioctl. If your device can do SR-IOV, then you can bind one
>>>>> process per virtual function.
>>>>>
>>>>> Unless we end up seeing lots of endpoints that implement PRI but not
>>>>> PASID, I don't plan to add this to VFIO or SMMUv3.
>>>>>
>>>>> For a PCIe endpoint, the requirements for SVM are ATS, PRI and PASID
>>>>> enabled. In addition, the SMMU should support DVM (broadcast TLB
>>>>> maintenance) and must be compatible with the MMU (page sizes, output
>>>>> address size, ASID bits...)
>>>>>
>>>> Thanks Jean.
>>>> In SMMU document it was quoted as follows
>>>> "When STE.S1DSS==0b10, a transaction without a SubstreamID is accepted and
>>>> uses the CD of Substream 0. Under this configuration, transactions that
>>>> arrive with SubstreamID 0 are aborted and an event recorded."
>>>>
>>>> Is this mode supported in your previous series of SMMUv3 patches ?
>>>> If it is supported is it achieved through VFIO ?
>>>
>>> Yes, STE.S1DSS==0b10 is the only supported mode with my patches. And in
>>> VFIO, the non-PASID context (CD 0) is managed with
>>> VFIO_IOMMU_MAP/UNMAP_DMA ioctls, mirroring the current behavior for
>>> devices that don't support PASID. All other CDs, with PASID > 0, are
>>> managed via the new BIND ioctl.
>>
>> Thanks Jean, this helps a lot.
>> So i digged through your patches and i understood that using BIND ioctls
>> satge-1 translations are setup in SMMU for an application.
>> If we use VFIO_IOMMU_MAP/UNMAP_DMA ioctls they are setting up stage-2
>> translations in SMMU.
>> So without PASID support we can only work with stage-2 translations ?
>
> It depends what type you use when registering the IOMMU with VFIO_SET_IOMMU:
>
> * If the type is VFIO_TYPE1v2_IOMMU, then VFIO_IOMMU_MAP/UNMAP_DMA
>   affects the stage-1 non-PASID context (already the case in mainline).
>   In addition, with my patch the BIND ioctl will affect stage-1 PASID
>   contexts, and bind process page directories to the device (host SVM).
>
> * If the type is VFIO_TYPE1_NESTING_IOMMU, then VFIO_IOMMU_MAP/UNMAP_DMA
>   will affect stage-2 mappings (already in mainline).
>   With my SMMU patch series, the BIND ioctl is not supported in this mode.
>   But in the future, BIND would allow to manage stage-1 as well:
>   - bind a process page directory (host SVM with added stage-2), or
>   - bind a guest page directory (viommu), or
>   - bind the full stage-1 context table (viommu).

Hi Jean, Thanks a lot for this information.
I tried to understand how stage-1 translations are setup if we use 
VFIO_TYPE1v2_IOMMU & VFIO_IOMMU_MAP/UNMAP_DMA flow, but I'm not 
successful, I couldn't find when context descriptor details are updated 
with stage-1 translation table details in this flow.
I found that in BIND flow a new context descriptor being created and 
assigned with required translation tables.

Can you please point to piece of code/patch series where and how context 
descriptor is updated for VFIO_IOMMU_MAP/UNMAP_DMA flow with 
VFIO_TYPE1v2_IOMMU.


Regards,
Valmiki