On Mon, 2011-11-21 at 15:35 -0800, Chris Wright wrote: > * Joerg Roedel (joro@xxxxxxxxxx) wrote: > > >From device standpoint a MSI transaction is always a DMA memory write > > to a given address range. The IOMMU-API should export a feature flag > > whether it supports filtering on those transaction or not. We have that > > today with the IOMMU_CAP_INTR_REMAP. I agree that the interface to get > > this information is ugly because a domain is needed. But the interface > > can be fixed. While doing this I suggest to rename that feature > > IOMMU_CAP_INTR_ISOLATION or something like that. > > VFIO can then check for this flag on module-load and refuse to load if > > it is not available. > > I can see that the native grouping (the typical pci bridge type) is > really more a property of the topology. > > The isolation properties of a group (arguably the whole point of the > group) is subtly different. Yes, there is a subtle difference there, maybe that's what we're tripping over. I see the group as an assertion by the iommu driver that it can distinguish and isolate the set of devices within that group from other groups and shared resources. For instance, numerous systems include hardware iommus that provide only translation and not isolation (DMA is translated through the IOVA window or allowed direct to memory). That doesn't mean they should implement a device_group callback that statically returns a single groupid, that means they should not implement device_group. I'm afraid the meaning of a group will be lost if we allow iommus to define groups, but then add flags saying "oh, but we don't isolate ________". I much prefer we enable a user to opt-in at the iommu driver level than weaken the definition of a group. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
