iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH v5 00/19] Shared virtual address IOMMU and VT-d support
Date: Mon, 26 Aug 2019 10:12:30 -0700	[thread overview]
Message-ID: <20190826101230.69785216@jacob-builder> (raw)
In-Reply-To: <1565900005-62508-1-git-send-email-jacob.jun.pan@linux.intel.com>

Hi Joerg and all,

Just wondering if you have more comments for this version. Since
the complete vSVA patchset is quite large, my hope is that we can make
incremental progress with smaller sets.

My plans are:
1. vSVA IOMMU APIs and VT-d support of PCI devices (this patchset)
2. Page request service
3. mdev support
4. code merge with Jean's generic sva_bind() APIs

For this set, we don't need PRS related patches (1-4). I included
them because they are in Jean's common API repo. Could you review 5-19
and consider for v5.4? This will make further submissions much easier.

Thanks,

Jacob

On Thu, 15 Aug 2019 13:13:06 -0700
Jacob Pan <jacob.jun.pan@linux.intel.com> wrote:

> Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on
> Intel platforms allow address space sharing between device DMA and
> applications. SVA can reduce programming complexity and enhance
> security. This series is intended to enable SVA virtualization, i.e.
> shared guest application address space and physical device DMA
> address. Only IOMMU portion of the changes are included in this
> series. Additional support is needed in VFIO and QEMU (will be
> submitted separately) to complete this functionality.
> 
> To make incremental changes and reduce the size of each patchset.
> This series does not inlcude support for page request services.
> 
> In VT-d implementation, PASID table is per device and maintained in
> the host. Guest PASID table is shadowed in VMM where virtual IOMMU is
> emulated.
> 
>     .-------------.  .---------------------------.
>     |   vIOMMU    |  | Guest process CR3, FL only|
>     |             |  '---------------------------'
>     .----------------/
>     | PASID Entry |--- PASID cache flush -
>     '-------------'                       |
>     |             |                       V
>     |             |                CR3 in GPA
>     '-------------'
> Guest
> ------| Shadow |--------------------------|--------
>       v        v                          v
> Host
>     .-------------.  .----------------------.
>     |   pIOMMU    |  | Bind FL for GVA-GPA  |
>     |             |  '----------------------'
>     .----------------/  |
>     | PASID Entry |     V (Nested xlate)
>     '----------------\.------------------------------.
>     |             |   |SL for GPA-HPA, default domain|
>     |             |   '------------------------------'
>     '-------------'
> Where:
>  - FL = First level/stage one page tables
>  - SL = Second level/stage two page tables
> 
> 
> This work is based on collaboration with other developers on the IOMMU
> mailing list. Notably,
> 
> [1] Common APIs git://linux-arm.org/linux-jpb.git sva/api
> 
> [2] [RFC PATCH 2/6] drivers core: Add I/O ASID allocator by
> Jean-Philippe Brucker
> https://www.spinics.net/lists/iommu/msg30639.html
> 
> [3] [RFC PATCH 0/5] iommu: APIs for paravirtual PASID allocation by
> Lu Baolu https://lkml.org/lkml/2018/11/12/1921
> 
> [4] [PATCH v5 00/23] IOMMU and VT-d driver support for Shared Virtual
>     Address (SVA)
>     https://lwn.net/Articles/754331/
> 
> There are roughly three parts:
> 1. Generic PASID allocator [1] with extension to support custom
> allocator 2. IOMMU cache invalidation passdown from guest to host
> 3. Guest PASID bind for nested translation
> 
> All generic IOMMU APIs are reused from [1] with minor tweaks. With
> this patchset, guest SVA without page request works on VT-d. PRS
> patches will come next as we try to avoid large patchset that is hard
> to review. The patches for basic SVA support (w/o PRS) starts:
> [PATCH v5 05/19] iommu: Introduce attach/detach_pasid_table API
> 
> It is worth noting that unlike sMMU nested stage setup, where PASID
> table is owned by the guest, VT-d PASID table is owned by the host,
> individual PASIDs are bound instead of the PASID table.
> 
> This series is based on the new VT-d 3.0 Specification
> (https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf).
> This is different than the older series in [4] which was based on the
> older specification that does not have scalable mode.
> 
> 
> ChangeLog:
> 	- V5
> 	  Rebased on v5.3-rc4 which has some of the IOMMU fault APIs
> merged. Addressed v4 review comments from Eric Auger, Baolu Lu, and
> 	    Jonathan Cameron. Specific changes are as follows:
> 	  - Refined custom IOASID allocator to support multiple
> vIOMMU, hotplug cases.
> 	  - Extracted vendor data from IOMMU guest PASID bind data,
> for VT-d will support all necessary guest PASID entry fields for PASID
> 	    bind.
> 	  - Support non-identity host-guest PASID mapping
> 	  - Exception handling in various cases
> 
> 	- V4
> 	  - Redesigned IOASID allocator such that it can support
> custom allocators with shared helper functions. Use separate XArray
> 	  to store IOASIDs per allocator. Took advice from Eric Auger
> to have default allocator use the generic allocator structure.
> 	  Combined into one patch in that the default allocator is
> just "another" allocator now. Can be built as a module in case of
> 	  driver use without IOMMU.
> 	  - Extended bind guest PASID data to support SMMU and
> non-identity guest to host PASID mapping
> https://lkml.org/lkml/2019/5/21/802
> 	  - Rebased on Jean's sva/api common tree, new patches starts
> with [PATCH v4 10/22]
> 
> 	- V3
> 	  - Addressed thorough review comments from Eric Auger (Thank
> you!)
> 	  - Moved IOASID allocator from driver core to IOMMU code per
> 	    suggestion by Christoph Hellwig
> 	    (https://lkml.org/lkml/2019/4/26/462)
> 	  - Rebased on top of Jean's SVA API branch and Eric's v7[1]
> 	    (git://linux-arm.org/linux-jpb.git sva/api)
> 	  - All IOMMU APIs are unmodified (except the new bind guest
> PASID call in patch 9/16)
> 
> 	- V2
> 	  - Rebased on Joerg's IOMMU x86/vt-d branch v5.1-rc4
> 	  - Integrated with Eric Auger's new v7 series for common APIs
> 	  (https://github.com/eauger/linux/tree/v5.1-rc3-2stage-v7)
> 	  - Addressed review comments from Andy Shevchenko and Alex
> Williamson on IOASID custom allocator.
> 	  - Support multiple custom IOASID allocators (vIOMMUs) and
> dynamic registration.
> 
> 
> Jacob Pan (14):
>   iommu: Add a timeout parameter for PRQ response
>   iommu: handle page response timeout
>   iommu: Introduce attach/detach_pasid_table API
>   iommu/ioasid: Add custom allocators
>   iommu: Introduce guest PASID bind function
>   iommu/vt-d: Add custom allocator for IOASID
>   iommu/vt-d: Replace Intel specific PASID allocator with IOASID
>   iommu/vt-d: Move domain helper to header
>   iommu/vt-d: Avoid duplicated code for PASID setup
>   iommu/vt-d: Add nested translation helper function
>   iommu/vt-d: Misc macro clean up for SVM
>   iommu/vt-d: Add bind guest PASID support
>   iommu/vt-d: Support flushing more translation cache types
>   iommu/vt-d: Add svm/sva invalidate function
> 
> Jean-Philippe Brucker (3):
>   trace/iommu: Add sva trace events
>   iommu: Use device fault trace event
>   iommu: Add I/O ASID allocator
> 
> Lu Baolu (1):
>   iommu/vt-d: Enlightened PASID allocation
> 
> Yi L Liu (1):
>   iommu: Introduce cache_invalidate API
> 
>  Documentation/admin-guide/kernel-parameters.txt |   8 +
>  drivers/iommu/Kconfig                           |   5 +
>  drivers/iommu/Makefile                          |   1 +
>  drivers/iommu/dmar.c                            |  46 +++
>  drivers/iommu/intel-iommu.c                     | 259 +++++++++++++-
>  drivers/iommu/intel-pasid.c                     | 343
> ++++++++++++++++--- drivers/iommu/intel-pasid.h
> |  25 +- drivers/iommu/intel-svm.c                       | 298
> +++++++++++++--- drivers/iommu/ioasid.c                          |
> 433 ++++++++++++++++++++++++
> drivers/iommu/iommu.c                           | 139 ++++++++
> include/linux/intel-iommu.h                     |  39 ++-
> include/linux/intel-svm.h                       |  17 +
> include/linux/ioasid.h                          |  75 ++++
> include/linux/iommu.h                           |  58 ++++
> include/trace/events/iommu.h                    |  84 +++++
> include/uapi/linux/iommu.h                      | 219 ++++++++++++ 16
> files changed, 1925 insertions(+), 124 deletions(-) create mode
> 100644 drivers/iommu/ioasid.c create mode 100644
> include/linux/ioasid.h
> 

[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

      parent reply	other threads:[~2019-08-26 17:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 20:13 [PATCH v5 00/19] Shared virtual address IOMMU and VT-d support Jacob Pan
2019-08-15 20:13 ` [PATCH v5 01/19] iommu: Add a timeout parameter for PRQ response Jacob Pan
2019-08-15 20:13 ` [PATCH v5 02/19] iommu: handle page response timeout Jacob Pan
2019-08-15 20:13 ` [PATCH v5 03/19] trace/iommu: Add sva trace events Jacob Pan
2019-08-15 20:13 ` [PATCH v5 04/19] iommu: Use device fault trace event Jacob Pan
2019-08-15 20:13 ` [PATCH v5 05/19] iommu: Introduce attach/detach_pasid_table API Jacob Pan
2019-08-15 20:13 ` [PATCH v5 06/19] iommu: Introduce cache_invalidate API Jacob Pan
2019-08-15 20:13 ` [PATCH v5 07/19] iommu: Add I/O ASID allocator Jacob Pan
2019-08-15 20:13 ` [PATCH v5 08/19] iommu/ioasid: Add custom allocators Jacob Pan
2019-08-15 20:13 ` [PATCH v5 09/19] iommu: Introduce guest PASID bind function Jacob Pan
2019-08-15 20:13 ` [PATCH v5 10/19] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-08-15 20:13 ` [PATCH v5 11/19] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-08-15 20:13 ` [PATCH v5 12/19] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-08-15 20:13 ` [PATCH v5 13/19] iommu/vt-d: Move domain helper to header Jacob Pan
2019-08-15 20:13 ` [PATCH v5 14/19] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-08-15 20:13 ` [PATCH v5 15/19] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-08-15 20:13 ` [PATCH v5 16/19] iommu/vt-d: Misc macro clean up for SVM Jacob Pan
2019-08-15 21:17   ` Andy Shevchenko
2019-08-15 22:50     ` Jacob Pan
2019-08-15 20:13 ` [PATCH v5 17/19] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-08-15 20:13 ` [PATCH v5 18/19] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-08-15 20:13 ` [PATCH v5 19/19] iommu/vt-d: Add svm/sva invalidate function Jacob Pan
2019-08-26 17:12 ` Jacob Pan [this message]

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=20190826101230.69785216@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe.brucker@arm.com \
    --cc=jic23@kernel.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).