Received-SPF: pass (google.com: domain of linux-kernel+bounces-136344-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>, "iommu@lists.linux.dev"
	<iommu@lists.linux.dev>
CC: "Liu, Yi L" <yi.l.liu@intel.com>, Joerg Roedel <joro@8bytes.org>, "Will
 Deacon" <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] iommu/vt-d: Avoid unnecessary device TLB flush in map
 path
Thread-Topic: [PATCH 1/2] iommu/vt-d: Avoid unnecessary device TLB flush in
 map path
Thread-Index: AQHaiPn/q4hRm40VZ0qfWlbJiHpMrrFfiK5A
Date: Tue, 9 Apr 2024 07:20:20 +0000
Message-ID: <BN9PR11MB5276DD9779553C20EF16BB4B8C072@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20240407144232.190355-1-baolu.lu@linux.intel.com>
In-Reply-To: <20240407144232.190355-1-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?7mBmoU52yo2CajSr/bBV/3eUX1zTsbAgrRWCJSwnndAxTn25XrHI5BFeapAM?=
 =?us-ascii?Q?f9vB25ziYnfrTt1U+SDjdsMzK5XZSIM+5/pIb6zFnOSXIw9XCi3VYlPYf0Y3?=
 =?us-ascii?Q?N44Tx7JzhhCuX1hK+xzzEU5797kHe6vH8kgW7AxdazDFjOfSyU0ZhaD7w1Tf?=
 =?us-ascii?Q?Q1HV/K66kmyscsM2pCpFIPvtkex+aMKYpit2Mo06pK/HYYXct/ihAxWaf+OW?=
 =?us-ascii?Q?d2+uds3cpAUHHzjLOXlcvBxLwx4ZMulTtNfSMZV/sROJGU3uGfD81BW7K7Ms?=
 =?us-ascii?Q?vVj0MOv5UB5/ZGptynmtgMD7M06tJBhyF3tb3wGO5dhTp+FlBUpQjl47hY21?=
 =?us-ascii?Q?s86N73Bg8h62A0WMwtXJOS3i45QcZMtr/YCOwF+sS/1wjGhrrCMJ9xUBemGw?=
 =?us-ascii?Q?2VlS+kan/nx1JauRHkc8uyn/fb9KtZ20PX7Vkjmkh+oZacdBeicjcgak2XmT?=
 =?us-ascii?Q?oVr8qggmldt9ZBGi8OcuItDM52oG2H5YQXnxUZXkLrtazsGfXqSk5UXH3i4u?=
 =?us-ascii?Q?jsmZ5FIUGPC0Cs7oFnvomLzHLe2qGTHg/2kYLJqEvC2AxOHeN1OZ+vv6T0zz?=
 =?us-ascii?Q?x44QpSdVJJI8fjIO2MvTvZVn4ePCEtUeRPP/Hh/pn0P0PQHy2tMKjFfaQQdC?=
 =?us-ascii?Q?QhMoti33SM+CL5JQhrd9arALfy7WcPETQPzlEalrKM5RihjLH27VU1f4p+gX?=
 =?us-ascii?Q?qdSJfbzdSN1ckf/DkJsFWsolE9y4M0brp2BtdlsmBwRLWCkupqNvebLZ+jfA?=
 =?us-ascii?Q?WIVxPqH3XweMsRWai5S5abUVjHQpi5wzcC1EaxrjWnWi8pn53hbUc3ScL24S?=
 =?us-ascii?Q?uS+pn6AM1HVDyMacotXYHaHcX4Cbfx9BIrtVvGjvpz5CfQZtvotcYcRAHoLC?=
 =?us-ascii?Q?CFuVEEg0/HyUHqpJQWvea+jnoNSl+l5EZS71lyeKUs/KpdCXT/ncLkJphwCM?=
 =?us-ascii?Q?ztM1bV1wu31BPIH5qo33VlCJJFz1eHpq6SUrxMc3hAnG/PSTvILxZr+vIs5G?=
 =?us-ascii?Q?R9UIf1Ia9K9VoaQKx5fC5HOa3kiaZ/YpPqRiJ1XcgXg2twtJGdNgcLG+nc+q?=
 =?us-ascii?Q?1INjkQoxcsJDfKZmmnhnh5Z+HxjnQb06ys9eUBo/Y38+CeFei6ZT8EfkstIF?=
 =?us-ascii?Q?cxxquVMAznvQttr/4rR8OxclAepUEuHXiAuZdgPN7vv57PnBSIXfXxRvQim9?=
 =?us-ascii?Q?4N4+SD+wbJ1GB87zZrAiNTRh9KQOLkwOVMo3P/8QKxM+jC7EJbxrm+I21Rvm?=
 =?us-ascii?Q?IDx7qvEx23ec7cpItO2T9GK6sggns0CoomC4zucKDctv33B9LKd/+hd15EL2?=
 =?us-ascii?Q?/wSUJ8VDwnlmw9Mh7d9NBJjUs045tPUnm4mw5H/FXdEvHuu6OOUf3a1O28CE?=
 =?us-ascii?Q?5FSGjm8YGndGgtYEahCgCAe7GAXkfQTxf52cb3soeORRTozZJQyDPG/ZMW7V?=
 =?us-ascii?Q?hAocmUsH/irJ4XSDiu+BOYcKeCR822yQEpGw4WhhE+ORsjy0NH/mQ3DrL0kt?=
 =?us-ascii?Q?MY2edBjPhzV1rV+0+Wm/rYMle9hBan8ddnz+Zbz1qVANCPouHQ2sTUrd9MSw?=
 =?us-ascii?Q?yOJzxcIAVOdc90DyZR1qPmRPsAMgaplu0dgY8icT?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
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: 66a2fcdb-f3ca-47fd-98cd-08dc586583c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2024 07:20:20.4820
 (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: Kh2ogDEsxRJSyp+pO0yYjK8FkN2lxHPZbpVFgKWcyl5f7rIkDH+nbzvn6KwmCo34Snl11Ak4PUCNQ8uOfLFkxg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6608
X-OriginatorOrg: intel.com

> From: Lu Baolu <baolu.lu@linux.intel.com>
> Sent: Sunday, April 7, 2024 10:43 PM
>=20
> iommu_flush_iotlb_psi() is called in map and unmap paths. The caching
> mode check before device TLB invalidation will cause device TLB
> invalidation always issued if IOMMU is not running in the caching mode.
> This is inefficient and causes performance overhead.

s/inefficient/wrong/

'inefficient' means that it's a right thing to do but just inefficient comp=
ared
to other options. But here by definition it's not required and caching mode
is irrelevant in the context of devtlb.

>=20
> Make device TLB invalidation behavior consistent between batched mode
> unmapping and strict mode unmapping. Device TLB invalidation should only

I don't quite understand the connection to batch vs. strict.

> be requested in the unmap path if the IOMMU is not in caching mode.

I'll remove the part about caching mode as it's irrelevant.

>=20
> Fixes: bf92df30df90 ("intel-iommu: Only avoid flushing device IOTLB for
> domain ID 0 in caching mode")
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> ---
>  drivers/iommu/intel/iommu.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
>=20
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 50eb9aed47cc..493b6a600394 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -1501,11 +1501,7 @@ static void iommu_flush_iotlb_psi(struct
> intel_iommu *iommu,
>  	else
>  		__iommu_flush_iotlb_psi(iommu, did, pfn, pages, ih);
>=20
> -	/*
> -	 * In caching mode, changes of pages from non-present to present
> require
> -	 * flush. However, device IOTLB doesn't need to be flushed in this
> case.
> -	 */
> -	if (!cap_caching_mode(iommu->cap) || !map)
> +	if (!cap_caching_mode(iommu->cap) && !map)
>  		iommu_flush_dev_iotlb(domain, addr, mask);

It's a bit strange to do this half-baked way and then rely on next patch
to do the right thing. It temporarily removes all devtlb invalidations
for caching mode here and then add them back for unmap in next patch.

caching mode has nothing to do with devtlb. So I'd just do:

	if (!map)
		iommu_flush_dev_iotlb(domain, addr, mask);