linux-kernel - Re: [PATCH v2 04/12] iommu/vt-d: Move scalable mode ATS enablement to probe 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: <6a418974-d06e-46e3-879f-ab4c84a95231@linux.intel.com>
Date: Wed, 26 Feb 2025 10:21:17 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: "Tian, Kevin" <kevin.tian@...el.com>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
 Jason Gunthorpe <jgg@...pe.ca>
Cc: "Jiang, Dave" <dave.jiang@...el.com>, Vinod Koul <vkoul@...nel.org>,
 Fenghua Yu <fenghuay@...dia.com>, Zhangfei Gao <zhangfei.gao@...aro.org>,
 Zhou Wang <wangzhou1@...ilicon.com>,
 "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 04/12] iommu/vt-d: Move scalable mode ATS enablement to
 probe path

On 2/25/25 15:28, Tian, Kevin wrote:
>> From: Lu Baolu <baolu.lu@...ux.intel.com>
>> Sent: Monday, February 24, 2025 1:16 PM
>>
>> Device ATS is currently enabled when a domain is attached to the device
>> and disabled when the domain is detached. This creates a limitation:
>> when the IOMMU is operating in scalable mode and IOPF is enabled, the
>> device's domain cannot be changed.
> 
> I got what this patch does, but not this description. Can you elaborate
> about the limitation?

Okay, sure.

The previous code enables ATS when a domain is set to a device's RID and
disables it during RID domain switch. So, if a PASID is set with a
domain requiring PRI, ATS should remain enabled until the domain is
removed. During the PASID domain's lifecycle, if the RID's domain
changes, PRI will be disrupted because it depends on ATS, which is
disabled when the blocking domain is set for the device's RID.

> 
>> @@ -1556,12 +1528,22 @@ domain_context_mapping(struct dmar_domain
>> *domain, struct device *dev)
>>   	struct device_domain_info *info = dev_iommu_priv_get(dev);
>>   	struct intel_iommu *iommu = info->iommu;
>>   	u8 bus = info->bus, devfn = info->devfn;
>> +	struct pci_dev *pdev;
>> +	int ret;
>>
>>   	if (!dev_is_pci(dev))
>>   		return domain_context_mapping_one(domain, iommu, bus,
>> devfn);
>>
>> -	return pci_for_each_dma_alias(to_pci_dev(dev),
>> -				      domain_context_mapping_cb, domain);
>> +	pdev = to_pci_dev(dev);
>> +	ret = pci_for_each_dma_alias(pdev, domain_context_mapping_cb,
>> domain);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (info->ats_supported && pci_ats_page_aligned(pdev) &&
>> +	    !pci_enable_ats(pdev, VTD_PAGE_SHIFT))
>> +		info->ats_enabled = 1;
>> +
>> +	return 0;
>>   }
> 
> It'd be good to add a note here for why legacy mode still requires
> dynamic toggle at attach/detach time. It's not obvious w/o knowing
> the story about legacy + identity.

"legacy + identity" is part of the reason. Additionally, in legacy mode,
the ATS control bit is defined as a translation type and should be set
together with the page table pointer in the context entry. Separating
ATS enablement and the translation page table into different places
would make the code more complex and fragile.

> btw the same enabling logic occurs in multiple places. Probably
> you can still make a helper for that.

Yes, I will make a helper like this,

+static void device_enable_pci_ats(struct pci_dev *pdev)
+{
+       struct device_domain_info *info = dev_iommu_priv_get(&pdev->dev);
+
+       if (!info->ats_supported)
+               return;
+
+       if (!pci_ats_page_aligned(pdev))
+               return;
+
+       if(!pci_enable_ats(pdev, VTD_PAGE_SHIFT))
+               info->ats_enabled = 1;
+}

> Otherwise,
> 
> Reviewed-by: Kevin Tian <kevin.tian@...el.com>

Thanks,
baolu