All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Bharat Kumar Gogada <bharatku@xilinx.com>,
	valmiki <valmikibow@gmail.com>,
	Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Lan, Tianyu" <tianyu.lan@intel.com>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>
Subject: RE: Support SVM without PASID
Date: Tue, 29 Aug 2017 01:32:11 +0000	[thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D190D956F6@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <BLUPR0201MB15051529B1A13F03B4CE7342A59E0@BLUPR0201MB1505.namprd02.prod.outlook.com>

> From: Bharat Kumar Gogada [mailto:bharatku@xilinx.com]
> Sent: Monday, August 28, 2017 9:10 PM
> 
> > Subject: RE: Support SVM without PASID
> >
> > > From: valmiki [mailto:valmikibow@gmail.com]
> > > Sent: Saturday, August 12, 2017 8:11 PM
> > >
> > > On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote:
> > > > On 05/08/17 06:14, valmiki wrote:
> > > > [...]
> > > >> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
> > > >> documentation we fill vaddr and iova in struct
> > > vfio_iommu_type1_dma_map
> > > >> and pass them to VFIO. But if we use dynamic allocation in
> > > >> application (say malloc), do we need to use dma API to get iova and
> > > >> then call VFIO_IOMMU_MAP ioctl ?
> > > >> If application needs multiple such dynamic allocations, then it
> > > >> need to allocate large chunk and program it via VFIO_IOMMU_MAP
> > > >> ioctl and
> > > then
> > > >> manage rest allocations requirements from this buffer ?
> > > >
> > > > Yes, without SVM, the application allocates large buffers, allocates
> > > > IOVAs itself, and maps them with VFIO_IOMMU_MAP. Userspace
> doesn't
> > > > rely
> > > on the
> > > > DMA API at all, it manages IOVAs as it wants. Sizes passed to
> > > > VFIO_IOMMU_MAP have to be multiples of the MMU or IOMMU page
> > > granularity
> > > > (that is at least 4kB), and both iova and vaddr have to be aligned
> > > > on that granularity as well. So malloc isn't really suitable in this
> > > > case, you'll need mmap. The application can then implement a small
> > > > allocator to
> > > manage
> > > > the DMA pool created with VFIO_IOMMU_MAP.
> > >
> > > Thanks Jean, I have a confusion allocate IOVA's in userspace means,
> > > how can user application decide IOVA address, can user application
> > > pick any random IOVA address ?
> > >
> >
> > yes, any address. In this mode the whole IOVA address space is owned by
> > application, which just needs to use VFIO_IOMMU_MAP to setup
> > IOVA->PA mapping in IOMMU (As Jean pointed out, input paramters
> > are iova and vaddr. VFIO will figure out pa corresponding to vaddr).
> >
> Hi Kevin, I have a doubt in this case, what if someone assigns mmap
> returned virtual address as iova address, then
> EP will assume it is generating request on IOVA but in reality we are using
> application allocated virtual address, then
> it looks like we are working with application virtual address directly without
> PASID. Is this valid ?
> 

IOMMU doesn't care what an address in the DMA transaction from
a device is. It cares only whether the DMA transaction has PASID
tagged or not, and then pursue different structure to walk corresponding 
I/O page table to get a translated address. Each I/O page table hosts
a standalone virtual address space. An application can implement a
new allocator to manage the address space (iova != vaddr), or simply
reuse malloc-ed virtual address (iova == vaddr), which is not what
hardware really cares about.

Thanks
Kevin

  reply	other threads:[~2017-08-29  1:32 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
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 [this message]
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=AADFC41AFE54684AB9EE6CBC0274A5D190D956F6@SHSMSX101.ccr.corp.intel.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bharatku@xilinx.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tianyu.lan@intel.com \
    --cc=valmikibow@gmail.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.