Messages in this thread | | | Date | Wed, 30 Mar 2022 11:30:08 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH RFC v2 02/11] iommu: Add iommu_group_singleton_lockdown() |
| |
On Wed, Mar 30, 2022 at 02:12:57PM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Wednesday, March 30, 2022 7:58 PM > > > > On Wed, Mar 30, 2022 at 06:50:11AM +0000, Tian, Kevin wrote: > > > > > One thing that I'm not very sure is about DMA alias. Even when physically > > > there is only a single device within the group the aliasing could lead > > > to multiple RIDs in the group making it non-singleton. But probably we > > > don't need support SVA on such device until a real demand comes? > > > > How can we have multiple RIDs in the same group and have only one > > device in the group? > > Alex may help throw some insight here. Per what I read from the code > looks like certain device can generate traffic with multiple RIDs.
IIRC "dma alias" refers to things like legacy PCI to PCIe bridges that do still have multiple PCI ID's behind the bridge used in configuration cycles however the PCI to PCIe bridge will tag all PCIe TLPs with its own RID because classic PCI has no way for the requestor to convey a RID to the bridge.
So, from a Linux perspective the group should have have multiple struct devices behind the bridge, the bridge itself, and the RID the IOMMU HW matches on is only the RID of the PCI bridge.
But we know this because we know there is classic PCI stuff in the heigharchy, so we can just mark that group as incompatible.
> > Add a flag to the group that positively indicates the group can never > > have more than one member, even after hot plug. eg because it is > > impossible due to ACS, or lack of bridges, and so on. > > OK, I see your point. It essentially refers to a singleton group which > is immutable to hotplug.
Yes, known at creation time, not retroactively enforced because someone used SVA
Jason
| |