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: <0e807eec-ce51-42e2-9290-dc90c4210888@linux.intel.com>
Date: Mon, 19 Aug 2024 15:09:00 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Vasant Hegde <vasant.hegde@....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>,
 Yi Liu <yi.l.liu@...el.com>
Cc: baolu.lu@...ux.intel.com, 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:
> 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?

Yeah! So, the iommu driver should basically control the PRI switch on
the PF whenever someone wants to use it on a VF.

We could simplify things by turning on PRI for the whole PF when the
first iopf-capable domain is attached to a VF. Then, we'd only turn it
off once all VFs have such domains detached.

Thanks,
baolu
Yeah, so the iommu driver should flip the PRI switch on the PF whenever
someone wants to turn it on for its VF.

We could change things up so that when the first iopf-capable domain is 
attached to any VF or PF, we turn on PRI for the whole device. Then, we
turn it off when every VF and PF have such domains detached.