Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 9cnCEjKqC0Pv0uVCBfb8g4jmvOL1JmcLuVbOpptGI2DKlYuo0vQggWVRq4uCm1aFRLbP1vX6Ac
 N090UbY6UGjQ==
IronPort-SDR: IzZGvtmnOazCD/bdR7ddiOefUMtd/AXraOiK6SBYoyzo+X5ZP/cBfdwwYrFpbll8uQyCUSKjPz
 m0Sm8Wk2hywA==
From:   "Luck, Tony" <tony.luck@intel.com>
To:     Jacob Pan <jacob.jun.pan@linux.intel.com>,
        Jason Gunthorpe <jgg@nvidia.com>
CC:     Christoph Hellwig <hch@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        Joerg Roedel <joro@8bytes.org>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "Tian, Kevin" <kevin.tian@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "wangzhou1@hisilicon.com" <wangzhou1@hisilicon.com>,
        "zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
        "vkoul@kernel.org" <vkoul@kernel.org>,
        David Woodhouse <dwmw2@infradead.org>
Subject: RE: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit
 flags
Thread-Topic: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit
 flags
Thread-Index: AQHXR/foStIq1WXEVUyqodFI447jQarh3/IAgAAZyAD//6FJIA==
Date:   Thu, 13 May 2021 16:44:14 +0000
Message-ID: <dd52760ab65a40328b4c1a26ddd0e1d0@intel.com>
References: <1620653108-44901-2-git-send-email-jacob.jun.pan@linux.intel.com>
        <20210510233749.GG1002214@nvidia.com>   <20210510203145.086835cc@jacob-builder>
        <20210511114848.GK1002214@nvidia.com>   <20210511091452.721e9a03@jacob-builder>
        <20210511163521.GN1002214@nvidia.com>   <20210511110550.477a434f@jacob-builder>
        <20210511194726.GP1002214@nvidia.com>   <YJt3tGlzFK3b4E82@infradead.org>
        <20210513060012.0fcc7653@jacob-builder> <20210513133834.GC1002214@nvidia.com>
 <20210513081050.5cf6a6ed@jacob-builder>
In-Reply-To: <20210513081050.5cf6a6ed@jacob-builder>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.5.1.3
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Precedence: bulk

> For shared workqueue, it can only generate DMA request with PASID. The
> submission is done by ENQCMDS (S for supervisor) instruction.
>
> If we were not to share page tables with init_mm, we need a system PASID
> that doing the same direct mapping in IOMMU page tables.

Note that for the currently envisioned kernel use cases for accelerators it
would be OK for this system PASID to just provide either:

1) A 1:1 mapping for physical addresses.  Kernel users of the accelerators
  would provide physical addresses in descriptors.
2) The same mapping that the kernel uses for its "1:1" map of all physical
    memory. Users would use kernel virtual addresses in that "1:1" range
    (e.g. those obtained from page_to_virt(struct page *p);)

If people want to use an accelerator on memory allocated by vmalloc()
things will get more complicated. But maybe we can delay solving that
problem until someone comes up with a real use case that needs to
do this?

-Tony