Date:   Fri, 10 Dec 2021 13:48:48 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc:     Lu Baolu <baolu.lu@linux.intel.com>,
        iommu@lists.linux-foundation.org,
        LKML <linux-kernel@vger.kernel.org>,
        Joerg Roedel <joro@8bytes.org>,
        Christoph Hellwig <hch@infradead.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        Jacob Pan <jacob.jun.pan@intel.com>,
        Raj Ashok <ashok.raj@intel.com>,
        "Kumar, Sanjay K" <sanjay.k.kumar@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Tony Luck <tony.luck@intel.com>, Yi Liu <yi.l.liu@intel.com>,
        "Tian, Kevin" <kevin.tian@intel.com>,
        Barry Song <21cnbao@gmail.com>,
        "Zanussi, Tom" <tom.zanussi@intel.com>,
        Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH 3/4] iommu/vt-d: Support PASID DMA for in-kernel usage
Message-ID: <20211210174848.GH6385@nvidia.com>
References: <1638884834-83028-1-git-send-email-jacob.jun.pan@linux.intel.com>
 <1638884834-83028-4-git-send-email-jacob.jun.pan@linux.intel.com>
 <20211208132255.GS6385@nvidia.com>
 <20211208111659.6de22e52@jacob-builder>
 <9f724b3a-6028-43d7-b4fc-d8a939e7b2cf@linux.intel.com>
 <20211209152113.64b817b9@jacob-builder>
 <921a766f-d826-2ca4-f739-4d196b32a681@linux.intel.com>
 <20211210095025.38af67ce@jacob-builder>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211210095025.38af67ce@jacob-builder>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?0TWRHduN/3HmuS9VtjNsJY9NIbwSFb1RovjUmPY5dLEwHXQp5lrz/GkpmsG3?=
 =?us-ascii?Q?+87TD7DiBuapd8ms+H13VoqAUyH4SzK34oINJT0qjRzJGmVMJQCIewqNt6ZF?=
 =?us-ascii?Q?QNFHH0roEkQeO5evIGLLOY2iBElmF3JGx4UFNJAqSm3q0XXAZNzlW/7AUiZy?=
 =?us-ascii?Q?Wdfyoe+68V8v111O2DDpoDgmTfhqMCWLWKwk40i8TxwW63jklKM9nSWeSSdD?=
 =?us-ascii?Q?HB/qaoUNrjdKT+/dPBYHF5TNcJz7w4i2UPyadlDW0bd5WYy5kNAduN5odGYu?=
 =?us-ascii?Q?BfFOCAQl+kJqFF97h+cqLYx+ATnFkZ/6nPWHBy0XHD+2e+Lzgh/xRPkrhVwu?=
 =?us-ascii?Q?qWzKIYozGI+qupbUQ5tDvgsFcUZbEy23DDUryva9FbjBM35cZoiX4X3+O+yG?=
 =?us-ascii?Q?hFc5j7kAxgSo8EheC74gBKTcGQX+ReXGWYfWiTJPgBaz/Ou6WfFvC48wXMWL?=
 =?us-ascii?Q?GzIOikByAav/RJ7jydQJahhQT288vfKdBeRudh47BKkTPUSgXtDYBzzsfpLt?=
 =?us-ascii?Q?fm8TMvhQbysRZzrQTYbUdTAqdk9ihuxmp4M/WTMShX6rSU07YUb2g6ATNW+d?=
 =?us-ascii?Q?YwKrthvZK+2kJraZgMsaEde0ieoPKqJ/c3ywCBlmDSp/5vGDZNfWmCLs/OmR?=
 =?us-ascii?Q?+aTgWivicYtgO2AbUW422hDq7gKJRhgHJ4/vZb38lDxoPWOACF7dKsol6gO+?=
 =?us-ascii?Q?kc/swoao+HuG1Wlo5VLkL9arq063JJjWqDgfyVjlr4dKyMS0tIOrS6a1fVL2?=
 =?us-ascii?Q?/PMFxtXMJevHNg4QAxXJivlJoWSG5pLp8k63d5AGoeHr+gyMK+/aoE3uVrae?=
 =?us-ascii?Q?fxwWOmzkIKIbNghM8hCWIDtm2FQPfvWO9v2u8Iqyj3pOTJMrP6gxew3n8DIQ?=
 =?us-ascii?Q?4bLLgg9YYEqPBCrxozF0CTKwwOHnwBio2bFyLmhSNTikZDgpK5Yg07Ovea/G?=
 =?us-ascii?Q?t/hvpUVKhZNxLe99oEFmxpBLOMygQ5BaDO0u3OZe2Khw7OIKhUWQL2rh/I9y?=
 =?us-ascii?Q?LyQ4M8Zca6+WcM3ape2/hd12d9VHj1QxbokTaKeJVBF93P/O+1A5Z/nodCiK?=
 =?us-ascii?Q?IPtNcU0ZZ/FV9Oe9R63JXM5WcaBJVzWBhaa30kixgJSBwfKiULfI6Fgw7lrq?=
 =?us-ascii?Q?re5YrheXP2vLNh7UIqn2XB7z5J1mDf1VQxcaoyWHIwKjXFJDop1JI+F0dnN4?=
 =?us-ascii?Q?HhZt1oAndsAq+PNuJNjB6NZ/s6OArckJPZO2evUepZDdWROYlK37Ll0v7Yg3?=
 =?us-ascii?Q?uv/Y18Qb2wt12ZbINjETtA3Pm22vIprhHvWdpshy5FP02b9mHxvaT3zMa9kH?=
 =?us-ascii?Q?LUy92FvAu01QBmDSznzlnlHIaZU/jyg6/9bZn749nP5ETcxCJb15yycjP4+f?=
 =?us-ascii?Q?etFIkFpfTICGutwRYxv3FDE+1fyGR6PUg77RMwrV9Y44xPagEdBlUahAPArP?=
 =?us-ascii?Q?HBTTYCW+LUD4oN4KKc4txM2naRsWtgL+jlxGC3qFb6dfxmTyIaCq94FESitN?=
 =?us-ascii?Q?iKJK4QzDrP7ljostaoEUrhQGMbbwQMwChjMZjmz2abfPvRN5wQonc1Wp+C/D?=
 =?us-ascii?Q?22/YM2ynVmEbZP7eC7A=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 369a3467-fe5f-43ba-35cc-08d9bc05532b
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2021 17:48:50.6772
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oaHMsTEHespnlgPCfH1qFnh7G7/GD9d+n53TGVEAUMrwq7QcaavBR3gkcTDusEl1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB5539
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Dec 10, 2021 at 09:50:25AM -0800, Jacob Pan wrote:

> > Tying pasid to an iommu_domain is not a good idea. An iommu_domain
> > represents an I/O address translation table. It could be attached to a
> > device or a PASID on the device.
> 
> I don;t think we can avoid storing PASID at domain level or the group's
> default domain. IOTLB flush is per domain. Default domain of DMA type
> is already tying to PASID0, right?

No, it is just wrong.

If the HW requires a list of everything that is connected to the
iommu_domain then it's private iommu_domain should have that list.

But it is a *list* not a single PASID.

If one device has 10 PASID's pointing to this domain you must flush
them all if that is what the HW requires.

Jason