Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Lu Baolu <baolu.lu@linux.intel.com>,
        Joerg Roedel <joro@8bytes.org>,
        "Jason Gunthorpe" <jgg@nvidia.com>,
        Christoph Hellwig <hch@infradead.org>,
        "Raj, Ashok" <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        "Jiang, Dave" <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>
CC:     Eric Auger <eric.auger@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Pan, Jacob jun" <jacob.jun.pan@intel.com>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Jean-Philippe Brucker" <jean-philippe@linaro.org>
Subject: RE: [PATCH v7 03/10] iommu/sva: Add iommu_sva_domain support
Thread-Topic: [PATCH v7 03/10] iommu/sva: Add iommu_sva_domain support
Thread-Index: AQHYa1GAWzo4qdZhTU6Id4ueE7eQ+K0tyd1Q
Date:   Tue, 24 May 2022 09:39:52 +0000
Message-ID: <BN9PR11MB5276982C37DFF0FEFC45BDD68CD79@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20220519072047.2996983-1-baolu.lu@linux.intel.com>
 <20220519072047.2996983-4-baolu.lu@linux.intel.com>
In-Reply-To: <20220519072047.2996983-4-baolu.lu@linux.intel.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?bgKQcsn0ExbUG+I1XKp45x9gMSrnUmpSF5ZdEpfUC1+Do51/Jw3wO3JanZFD?=
 =?us-ascii?Q?nUdPRXSXf9expaNSxPiGGf+nRoirA1zltjzyHqdoK90FlT7kdTd0RW++y6yr?=
 =?us-ascii?Q?2vW9t09Wwsi0b1YxTUvjDH/3fOTxYuVHedxjC9eDfZzG6kQL+8MCy6OYj/cN?=
 =?us-ascii?Q?0V4gaLP9WM7xpZWPjBPsL/Vds2e3EdcskeaSWpyYIgAnmbam0gCUHiwVd8aO?=
 =?us-ascii?Q?d3s+3Rf7rmcDbadb0FlNScdlVmnDzUm0wlxP6zeErQ0RI5lfpIvi/V0D2r18?=
 =?us-ascii?Q?RDLgxQITSdkt5dVtgdI9NGNw7p+CgoMd9k3hb8TqtYwqj6uTuQKX/SeVzAl0?=
 =?us-ascii?Q?i8h6aEDoKiB/eON5RU8Rv14oPdS+vRiVuwGLrPlwyLTQdnUFKCR51B2Xf9AS?=
 =?us-ascii?Q?YAxsV3id8m26IffqmXoA2KQraCkIOM0IQRWnQqenP/gS3aat0SiVo+KzS1jA?=
 =?us-ascii?Q?ewTQe0XqiztZGsnHpPghIqGigpcW1CCz7IbLwXmcqjohj2KfjCepzX2jvCSl?=
 =?us-ascii?Q?lhD22orb+rtRkaFAUMqXz0iw3On8LPg8rjq4VdgFEehkg8BYPZZviS8E01DV?=
 =?us-ascii?Q?mLS5nddQ43dMkg9XA9ZxIbkz4p21k3lMfOYPb9pk7pZKHaEAohxoLrokUqOq?=
 =?us-ascii?Q?Zyne2/+pRWuQkwVxcgFvtGdLhY4uzyZVeHQdpRYptPNIyq8e8OLUxq6i5GZz?=
 =?us-ascii?Q?dXmVF7jWiBVvLAMkMbuqcDHNXDfGrV9IbL1cD6Yj/qFt4S4bX/SyUEG9mxi+?=
 =?us-ascii?Q?faU/jHLWM8ZMxAU/eV/eyMY9Twygffhv6Zp3P7DvBp9kha4Pr9/GqMj+B9t0?=
 =?us-ascii?Q?CEixMX96jsbyGDTM5UnHZ4I0OR54NqRIKy9dsNYi6bJH3Lo99PId8u+SHlp0?=
 =?us-ascii?Q?n28FyHrMdrlTZKBuqP5PIH9kC/VhWiTtpsSQTmzwg8Q8igwKqRtkaWDjp0f1?=
 =?us-ascii?Q?1FHyKcklkBSLpGn+C3aYfXKMh7x+LTVH5Sac+5+5R/F5wHzQ1tngZjsdk5Qg?=
 =?us-ascii?Q?UT0Jnm7of5ZVN894hnaQkHINIxDASFjxO2gJ58WgROuuGhT5sN8+UwNJzE6P?=
 =?us-ascii?Q?O1PYQtgvNV361FPZksNjpnB/JZUKB4TNh9r6PoONw6PgYOCreP5mHfxg7ARS?=
 =?us-ascii?Q?RbvHcmdnQCtlUWGghr5JHPBnR4vw2UD5bMfyDesE3YJooBbuxW1Znn88t2vm?=
 =?us-ascii?Q?XqC6SeSTFcHktJqxsdwYhoBtQB3KjwldINQEEH/iyAkxb+F+Yx0PoGSVSwzw?=
 =?us-ascii?Q?f1fioh63mh+adO2gJUyHO+6h53H5CGBsq22yRIwRGk3T+BakmIGq+DCoFiqt?=
 =?us-ascii?Q?Q7ri8koDmNtTNi2zzBrcwiwHTvN1chQzYi8xQAQcVt9Kem5NEGkdxG3SqN1O?=
 =?us-ascii?Q?+XQvpbZnxcOOqGZULtirAI0TvvIozR2evGCMagfoXlvD3nYRs4w6nYUswSrE?=
 =?us-ascii?Q?DTLixxbROa6rm1cjQcty1pQgWvm+J2BMewvEu/5Re7b6jz9rrj9HotvcPTIF?=
 =?us-ascii?Q?rCez2IdSQ4BQyMowyyqa8uYPLQ515RBVfAYTaZVbrle6wNdB3uZTWvkQh20F?=
 =?us-ascii?Q?6AImpMK7aq5GBRP2AECarFlUtj9W7OVrIFSUDzg5qeRyr6voe3ZQjqB3e9+Q?=
 =?us-ascii?Q?SmM+cGNv+kCB3Z9ePcvRuBc8Yi1Lxed+RqZ5ak5HabUNjHw593ZSKOEDoOjO?=
 =?us-ascii?Q?YsNWbpRDAQlRa9jv3yiVH9dCpLZdKffeYsOUEmDGXjUHO8TFISeBLZ/uwRcF?=
 =?us-ascii?Q?prjgeDjIpw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bf7f6bf-2949-4e06-68b4-08da3d695a44
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2022 09:39:52.1171
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8lOD7iOmQr7c09d5Fh975a47Ikfp+Ye7DZGYIlHzyMdEy9NadJu6GyoYl5W2G1yCdH6A/xZWWNxKdlx/VscR8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4034
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Lu Baolu <baolu.lu@linux.intel.com>
> Sent: Thursday, May 19, 2022 3:21 PM
>=20
> The iommu_sva_domain represents a hardware pagetable that the IOMMU
> hardware could use for SVA translation. This adds some infrastructure
> to support SVA domain in the iommu common layer. It includes:
>=20
> - Add a new struct iommu_sva_domain and new IOMMU_DOMAIN_SVA
> domain
>   type.
> - Add a new domain ops pointer in iommu_ops. The IOMMU drivers that
>   support SVA should provide the callbacks.
> - Add helpers to allocate and free an SVA domain.
> - Add helpers to set an SVA domain to a device and the reverse
>   operation.
>=20
> Some buses, like PCI, route packets without considering the PASID value.
> Thus a DMA target address with PASID might be treated as P2P if the
> address falls into the MMIO BAR of other devices in the group. To make
> things simple, the attach/detach interfaces only apply to devices
> belonging to the singleton groups, and the singleton is immutable in
> fabric i.e. not affected by hotplug.
>=20
> The iommu_set/block_device_pasid() can be used for other purposes,
> such as kernel DMA with pasid, mediation device, etc. Hence, it is put
> in the iommu.c.

usually we have 'set/clear' pair or 'allow/block'. Having 'set' paired
with 'block' doesn't read very clearly.

> +static bool device_group_immutable_singleton(struct device *dev)
> +{
> +	struct iommu_group *group =3D iommu_group_get(dev);

what about passing group as the parameter since the caller will
get the group again right after calling this function? In that case
the function could be renamed as:

	iommu_group_immutable_singleton()

or be shorter:

	iommu_group_fixed_singleton()

> +	int count;
> +
> +	if (!group)
> +		return false;
> +
> +	mutex_lock(&group->mutex);
> +	count =3D iommu_group_device_count(group);
> +	mutex_unlock(&group->mutex);
> +	iommu_group_put(group);
> +
> +	if (count !=3D 1)
> +		return false;

For non-pci devices above doesn't check anything against immutable.
Please add some comment to explain why doing so is correct.

> +
> +	/*
> +	 * The PCI device could be considered to be fully isolated if all
> +	 * devices on the path from the device to the host-PCI bridge are
> +	 * protected from peer-to-peer DMA by ACS.
> +	 */
> +	if (dev_is_pci(dev))
> +		return pci_acs_path_enabled(to_pci_dev(dev), NULL,
> +					    REQ_ACS_FLAGS);
> +
> +	return true;
> +}
> +