All of lore.kernel.org
 help / color / mirror / Atom feed
From: valmiki <valmikibow@gmail.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	Alex Williamson <alex.williamson@redhat.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
Subject: Re: Support SVM without PASID
Date: Sat, 22 Jul 2017 07:35:31 +0530	[thread overview]
Message-ID: <41333a03-bf91-1152-4779-6579845609f6@gmail.com> (raw)
In-Reply-To: <ca0d9f94-f5e2-aaaf-2c64-0cd6ecc62754@arm.com>

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

  reply	other threads:[~2017-07-22  2:05 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-08 17:03 Support SVM without PASID valmiki
2017-07-08 17:03 ` valmiki
2017-07-08 20:02 ` Alex Williamson
2017-07-08 20:02   ` Alex Williamson
2017-07-09  3:15   ` valmiki
2017-07-09  9:29     ` Liu, Yi L
2017-07-10  0:14     ` Bob Liu
2017-07-10  0:14       ` Bob Liu
2017-07-10 19:31     ` Jerome Glisse
2017-07-12 16:23       ` valmiki
2017-07-12 16:23         ` valmiki
2017-07-11 10:56     ` Jean-Philippe Brucker
2017-07-11 10:56       ` Jean-Philippe Brucker
2017-07-12 16:27       ` valmiki
2017-07-12 16:27         ` valmiki
2017-07-12 16:48         ` Jean-Philippe Brucker
2017-07-22  2:05           ` valmiki [this message]
2017-08-01  8:26             ` Jean-Philippe Brucker
2017-08-01  8:26               ` Jean-Philippe Brucker
2017-08-01 17:38               ` valmiki
2017-08-01 17:38                 ` valmiki
2017-08-01 18:40                 ` Jean-Philippe Brucker
2017-08-05  5:14                   ` valmiki
2017-08-07 10:31                     ` Jean-Philippe Brucker
2017-08-07 12:18                       ` Bob Liu
2017-08-07 12:18                         ` Bob Liu
2017-08-07 12:52                         ` Jean-Philippe Brucker
2017-08-08  0:51                           ` Bob Liu
2017-08-08  0:51                             ` Bob Liu
2017-08-09 15:01                             ` Jean-Philippe Brucker
2017-08-11  6:41                           ` Tian, Kevin
2017-08-11  9:25                             ` Jean-Philippe Brucker
2017-08-11  9:25                               ` Jean-Philippe Brucker
2017-08-11  9:36                             ` Bob Liu
2017-08-12 12:10                       ` valmiki
2017-08-14  7:49                         ` Tian, Kevin
2017-08-28 13:10                           ` Bharat Kumar Gogada
2017-08-28 13:10                             ` Bharat Kumar Gogada
2017-08-29  1:32                             ` Tian, Kevin
2017-08-04  1:49               ` Tian, Kevin
2017-08-04  1:49                 ` Tian, Kevin
2017-08-04  9:42                 ` Jean-Philippe Brucker
2017-08-11  6:29                   ` Tian, Kevin
2017-08-11  6:29                     ` Tian, Kevin
2017-08-11 16:25                   ` Raj, Ashok
2017-08-14  8:00                     ` Tian, Kevin
2017-08-14  8:00                       ` Tian, Kevin
2017-08-14  9:07                       ` Jean-Philippe Brucker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41333a03-bf91-1152-4779-6579845609f6@gmail.com \
    --to=valmikibow@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tianyu.lan@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.