From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Pan Subject: Re: [PATCH 00/18] Shared virtual address IOMMU and VT-d support Date: Mon, 15 Apr 2019 10:25:02 -0700 Message-ID: <20190415102502.3a47b24b@jacob-builder> References: <1554767973-30125-1-git-send-email-jacob.jun.pan@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1554767973-30125-1-git-send-email-jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, LKML , Joerg Roedel , David Woodhouse , Alex Williamson , Jean-Philippe Brucker Cc: "Tian, Kevin" , Raj Ashok , Andriy Shevchenko List-Id: iommu@lists.linux-foundation.org Hi Joerg and all, Just a gentle reminder if you have any comments on this series. The goal is to support vSVA but without page request. It shares code with Eric Auger's series sMMU v3 for nested mode. Jean, I took your ioasid allocator and modified for PASID allocation as we discussed for the need of custom allocator both for vt-d and pvIOMMU. Thanks, Jacob On Mon, 8 Apr 2019 16:59:15 -0700 Jacob Pan 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] [PATCH v6 00/22] SMMUv3 Nested Stage Setup by Eric Auger > https://lkml.org/lkml/2019/3/17/124 > > [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 > > 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], which has a v7 just > published with no real impact to the patches used here. 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. > > > Jacob Pan (15): > ioasid: Add custom IOASID allocator > ioasid: Convert ioasid_idr to XArray > driver core: add per device iommu param > iommu: introduce device fault data > iommu: introduce device fault report API > iommu: Introduce attach/detach_pasid_table API > iommu/vt-d: Add custom allocator for IOASID > iommu/vt-d: Replace Intel specific PASID allocator with IOASID > iommu: Add guest PASID bind function > iommu/vt-d: Move domain helper to header > iommu/vt-d: Add nested translation support > iommu/vt-d: Add bind guest PASID support > iommu: add max num of cache and granu types > iommu/vt-d: Support flushing more translation cache types > iommu/vt-d: Add svm/sva invalidate function > > Jean-Philippe Brucker (1): > drivers core: Add I/O ASID allocator > > Liu, Yi L (1): > iommu: Introduce cache_invalidate API > > Lu Baolu (1): > iommu/vt-d: Enlightened PASID allocation > > drivers/base/Kconfig | 7 ++ > drivers/base/Makefile | 1 + > drivers/base/ioasid.c | 211 > +++++++++++++++++++++++++++++++++++++ drivers/iommu/Kconfig | > 1 + drivers/iommu/dmar.c | 48 +++++++++ > drivers/iommu/intel-iommu.c | 219 > ++++++++++++++++++++++++++++++++++++-- drivers/iommu/intel-pasid.c | > 191 +++++++++++++++++++++++++++++----- drivers/iommu/intel-pasid.h | > 24 ++++- drivers/iommu/intel-svm.c | 217 > +++++++++++++++++++++++++++++++++++--- drivers/iommu/iommu.c | > 207 +++++++++++++++++++++++++++++++++++- include/linux/device.h > | 3 + include/linux/intel-iommu.h | 40 +++++-- > include/linux/intel-svm.h | 7 ++ > include/linux/ioasid.h | 66 ++++++++++++ > include/linux/iommu.h | 127 +++++++++++++++++++++++ > include/uapi/linux/iommu.h | 248 > ++++++++++++++++++++++++++++++++++++++++++++ 16 files changed, 1559 > insertions(+), 58 deletions(-) create mode 100644 > drivers/base/ioasid.c create mode 100644 include/linux/ioasid.h > create mode 100644 include/uapi/linux/iommu.h > [Jacob Pan] From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFFBFC10F0E for ; Mon, 15 Apr 2019 17:22:27 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9763F2183F for ; Mon, 15 Apr 2019 17:22:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9763F2183F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 43E8EB3E; Mon, 15 Apr 2019 17:22:27 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A93012C for ; Mon, 15 Apr 2019 17:22:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F3558823 for ; Mon, 15 Apr 2019 17:22:25 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2019 10:22:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,354,1549958400"; d="scan'208";a="316168612" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga005.jf.intel.com with ESMTP; 15 Apr 2019 10:22:25 -0700 Date: Mon, 15 Apr 2019 10:25:02 -0700 From: Jacob Pan To: iommu@lists.linux-foundation.org, LKML , Joerg Roedel , David Woodhouse , Alex Williamson , Jean-Philippe Brucker Subject: Re: [PATCH 00/18] Shared virtual address IOMMU and VT-d support Message-ID: <20190415102502.3a47b24b@jacob-builder> In-Reply-To: <1554767973-30125-1-git-send-email-jacob.jun.pan@linux.intel.com> References: <1554767973-30125-1-git-send-email-jacob.jun.pan@linux.intel.com> Organization: OTC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: "Tian, Kevin" , Raj Ashok , Andriy Shevchenko X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Message-ID: <20190415172502.oWChSQUF_8wPMYsBluXLfIg1NmYf6STvAjHaYt9nhKY@z> Hi Joerg and all, Just a gentle reminder if you have any comments on this series. The goal is to support vSVA but without page request. It shares code with Eric Auger's series sMMU v3 for nested mode. Jean, I took your ioasid allocator and modified for PASID allocation as we discussed for the need of custom allocator both for vt-d and pvIOMMU. Thanks, Jacob On Mon, 8 Apr 2019 16:59:15 -0700 Jacob Pan 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] [PATCH v6 00/22] SMMUv3 Nested Stage Setup by Eric Auger > https://lkml.org/lkml/2019/3/17/124 > > [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 > > 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], which has a v7 just > published with no real impact to the patches used here. 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. > > > Jacob Pan (15): > ioasid: Add custom IOASID allocator > ioasid: Convert ioasid_idr to XArray > driver core: add per device iommu param > iommu: introduce device fault data > iommu: introduce device fault report API > iommu: Introduce attach/detach_pasid_table API > iommu/vt-d: Add custom allocator for IOASID > iommu/vt-d: Replace Intel specific PASID allocator with IOASID > iommu: Add guest PASID bind function > iommu/vt-d: Move domain helper to header > iommu/vt-d: Add nested translation support > iommu/vt-d: Add bind guest PASID support > iommu: add max num of cache and granu types > iommu/vt-d: Support flushing more translation cache types > iommu/vt-d: Add svm/sva invalidate function > > Jean-Philippe Brucker (1): > drivers core: Add I/O ASID allocator > > Liu, Yi L (1): > iommu: Introduce cache_invalidate API > > Lu Baolu (1): > iommu/vt-d: Enlightened PASID allocation > > drivers/base/Kconfig | 7 ++ > drivers/base/Makefile | 1 + > drivers/base/ioasid.c | 211 > +++++++++++++++++++++++++++++++++++++ drivers/iommu/Kconfig | > 1 + drivers/iommu/dmar.c | 48 +++++++++ > drivers/iommu/intel-iommu.c | 219 > ++++++++++++++++++++++++++++++++++++-- drivers/iommu/intel-pasid.c | > 191 +++++++++++++++++++++++++++++----- drivers/iommu/intel-pasid.h | > 24 ++++- drivers/iommu/intel-svm.c | 217 > +++++++++++++++++++++++++++++++++++--- drivers/iommu/iommu.c | > 207 +++++++++++++++++++++++++++++++++++- include/linux/device.h > | 3 + include/linux/intel-iommu.h | 40 +++++-- > include/linux/intel-svm.h | 7 ++ > include/linux/ioasid.h | 66 ++++++++++++ > include/linux/iommu.h | 127 +++++++++++++++++++++++ > include/uapi/linux/iommu.h | 248 > ++++++++++++++++++++++++++++++++++++++++++++ 16 files changed, 1559 > insertions(+), 58 deletions(-) create mode 100644 > drivers/base/ioasid.c create mode 100644 include/linux/ioasid.h > create mode 100644 include/uapi/linux/iommu.h > [Jacob Pan] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu