Re: Support SVM without PASID

[Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>]

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).

Thanks,
Jean