[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220402232900.GL2120790@nvidia.com>
Date: Sat, 2 Apr 2022 20:29:00 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: "Raj, Ashok" <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@...radead.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"Pan, Jacob jun" <jacob.jun.pan@...el.com>,
Jean-Philippe Brucker <jean-philippe@...aro.com>,
Robin Murphy <robin.murphy@....com>,
"Alex Williamson (alex.williamson@...hat.com)"
<alex.williamson@...hat.com>
Subject: Re: [PATCH RFC v2 02/11] iommu: Add iommu_group_singleton_lockdown()
On Sat, Apr 02, 2022 at 07:12:12AM +0000, Tian, Kevin wrote:
> That is one scenario of dma aliasing. Another is like Alex replied where
> one device has an alias requestor ID due to PCI quirks. The alias RID
> may or may not map to a real device but probably what we really care
> here regarding to p2p are struct devices listed in the group.
Those devices are just broken and not spec complaint. IMHO we can
treat them as disabling ACS for their segment as well.
> We may check following conditions to set the immutable flag when
> a new group is created for a device in pci_device_group():
>
> 1) ACS is enabled in the upstream path of the device;
> 2) the device is single function or ACS is enabled on a multi-function device;
> 3) the device type is PCI_EXP_TYPE_ENDPOINT (thus no hotplug);
> 4) no 'dma aliasing' on this device;
It makes sense to me
Jason
Powered by blists - more mailing lists