linux-kernel - Re: [PATCH 1/1] iommu/vt-d: Move PCI PASID 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: <d21f61d7-71ab-404d-9378-72b1c893ee5c@intel.com>
Date: Mon, 19 Aug 2024 15:32:25 +0800
From: Yi Liu <yi.l.liu@...el.com>
To: Vasant Hegde <vasant.hegde@....com>, Baolu Lu <baolu.lu@...ux.intel.com>,
	Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>, Robin Murphy
	<robin.murphy@....com>, Jason Gunthorpe <jgg@...pe.ca>, Kevin Tian
	<kevin.tian@...el.com>
CC: <iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] iommu/vt-d: Move PCI PASID enablement to probe path

On 2024/8/19 14:34, Vasant Hegde wrote:
> Hi,
> 
> 
> On 8/16/2024 6:39 PM, Baolu Lu wrote:
>> On 2024/8/16 20:16, Vasant Hegde wrote:
>>> On 8/16/2024 4:19 PM, Lu Baolu wrote:
>>>> Currently, PCI PASID is enabled alongside PCI ATS when an iommu domain is
>>>> attached to the device and disabled when the device transitions to block
>>>> translation mode. This approach is inappropriate as PCI PASID is a device
>>>> feature independent of the type of the attached domain.
>>> Reading through other thread, I thought we want to enable both PASID and PRI in
>>> device probe path. Did I miss something?
>>
>> PRI is different. PRI should be enabled when the first iopf-capable
>> domain is attached to device or its PASID, and disabled when the last
>> such domain is detached.
> 
> Right. That's what AMD driver also does (We enable it when we attach IOPF
> capable domain). But looking into pci_enable_pri() :
> 
> 
> 202         /*
> 203          * VFs must not implement the PRI Capability.  If their PF
> 204          * implements PRI, it is shared by the VFs, so if the PF PRI is
> 205          * enabled, it is also enabled for the VF.
> 206          */
> 207         if (pdev->is_virtfn) {
> 208                 if (pci_physfn(pdev)->pri_enabled)
> 209                         return 0;
> 210                 return -EINVAL;
> 211         }
> 212
> 
> 
> If we try to enable PRI for VF without first enabling it in PF it will fail right?
> 
> Now if PF is attached to non-IOPF capable domain (like in AMD case attaching to
> domain with V1 page table) and we try to attach VF to IOPF capable domain  (say
> AMD v2 page table -OR- nested domain) it will fail right?

It looks like iommufd does not support it for VF. Baolu's iopf series 
disallowed it since v7. And the code in the below acts it.

+	/*
+	 * Once we turn on PCI/PRI support for VF, the response failure code
+	 * should not be forwarded to the hardware due to PRI being a shared
+	 * resource between PF and VFs. There is no coordination for this
+	 * shared capability. This waits for a vPRI reset to recover.
+	 */
+	if (dev_is_pci(dev) && to_pci_dev(dev)->is_virtfn)
+		return -EINVAL;


v6: 
https://lore.kernel.org/linux-iommu/20240527040517.38561-1-baolu.lu@linux.intel.com/
  - Refine the attach handle code by shifting the handle allocation to
    the caller. The caller will then provide the allocated handle to the
    domain attachment interfaces.
  - Add reference counter in iommufd_fault_iopf_enable/disable() helpers.
  - Fix the return values of fault FD's read/write fops.
  - Add IOMMU_CAP_USER_IOASID_TABLE capability and check it before roll
    back getting attach_handle to RID.
  - Move the iopf respond queue from iommufd device to iommufd fault.
  - Disallow PRI enablement on SR-IOV VF devices.

-- 
Regards,
Yi Liu