[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276371ACFE0B5CEAAA021C88C78A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 24 Jun 2025 08:33:29 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, "Will
Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>
CC: "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH 1/1] iommu/vt-d: Enable ATS before cache tag assignment
> From: Lu Baolu <baolu.lu@...ux.intel.com>
> Sent: Friday, June 20, 2025 2:08 PM
>
> Commit <4f1492efb495> ("iommu/vt-d: Revert ATS timing change to fix boot
> failure") placed the enabling of ATS in the probe_finalize callback. This
> occurs after the default domain attachment, which is when the ATS cache
> tag is assigned. Consequently, the device TLB cache tag is missed when the
> domain is attached, leading to the device TLB not being invalidated in the
> iommu_unmap paths.
>
> Fix it by moving the ATS enabling to the default domain attachment path,
> ensuring ATS is enabled before the cache tag assignment.
this means ATS will never be enabled for drivers with driver_managed_dma
set to '1', as they don't expect their devices attached to the default domain
automatically.
does it make more sense sticking to current way (enabling ATS in
probe_finalize) and assigning cache tag for device tlb at that point?
Powered by blists - more mailing lists