On 10/12/2018 08:57, '[email protected]' wrote: > Hi Kevin, > > On Mon, Dec 10, 2018 at 02:06:44AM +0000, Tian, Kevin wrote: >> Can I interpret above as that you agree with the aux domain concept (i.e. one >> device can be linked to multiple domains) in general, and now we're just >> trying >> to address the remaining open in API level? > > Yes, I thouht about alternatives, but in the end they are all harder to > use than the aux-domain concept. We just need to make sure that we have > a clear definition of what the API extension do and how they impact the > behavior of existing functions. > >>> enum iommu_dev_features { >>> /* ... */ >>> IOMMU_DEV_FEAT_AUX, >>> IOMMU_DEV_FEAT_SVA, >>> /* ... */ >>> }; >>> >> >> Does above represent whether a device implements aux/sva features, >> or whether a device has been enabled by driver to support aux/sva >> features? > > These represent whether the device together with the IOMMU support them, > basically whether these features are usable via the IOMMU-API. > > >> >>> /* Check if a device supports a given feature of the IOMMU-API */ >>> bool iommu_dev_has_feature(struct device *dev, enum >>> iommu_dev_features *feat); >> >> If the latter we also need iommu_dev_set_feature so driver can poke >> it based on its own configuration. > > Do you mean we need an explict enable-API for the features? I thought > about that too, but some features clearly don't need it and I didn't > want to complicate the usage. My assumption was that when the feature is > available, it is also enabled.
The cost of enabling those features for a device does seem negligible. For the SMMU we need to allocate about 70k of additional memory for the initial PASID table, but enabling the PASID cap shouldn't add any overhead otherwise. Same for PRI, shouldn't add any overhead. As for ATS, it supposedly makes things faster, although it does mean more invalidation requests. There currently is a global pci=noats parameter, but maybe we need something with finer granularity to enable/disable it per device? Thanks, Jean _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
