linux-kernel - RE: [PATCH 1/2] iommu/vt-d: Avoid unnecessary device TLB flush in map path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276DD9779553C20EF16BB4B8C072@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 9 Apr 2024 07:20:20 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Lu Baolu <baolu.lu@...ux.intel.com>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>
CC: "Liu, Yi L" <yi.l.liu@...el.com>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] iommu/vt-d: Avoid unnecessary device TLB flush in map
 path

> From: Lu Baolu <baolu.lu@...ux.intel.com>
> Sent: Sunday, April 7, 2024 10:43 PM
> 
> 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 compared
to other options. But here by definition it's not required and caching mode
is irrelevant in the context of devtlb.

> 
> 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.

> 
> Fixes: bf92df30df90 ("intel-iommu: Only avoid flushing device IOTLB for
> domain ID 0 in caching mode")
> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
> ---
>  drivers/iommu/intel/iommu.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> 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);
> 
> -	/*
> -	 * 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);