From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f67.google.com ([74.125.83.67]:34796 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751922AbdGVCF3 (ORCPT ); Fri, 21 Jul 2017 22:05:29 -0400 Subject: Re: Support SVM without PASID To: Jean-Philippe Brucker , Alex Williamson References: <20170708140257.2de02d63@w520.home> <73619426-6fcc-21ce-cfd4-8c66bde63f9a@gmail.com> Cc: iommu@lists.linux-foundation.org, kvm@vger.kernel.org, linux-pci@vger.kernel.org, tianyu.lan@intel.com, kevin.tian@intel.com, jacob.jun.pan@intel.com From: valmiki Message-ID: <41333a03-bf91-1152-4779-6579845609f6@gmail.com> Date: Sat, 22 Jul 2017 07:35:31 +0530 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Sender: linux-pci-owner@vger.kernel.org List-ID: 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 ? Regards, valmiki