> From: '[email protected]' [mailto:[email protected]] > Sent: Wednesday, December 12, 2018 5:54 PM > > Hi Kevin, > > On Wed, Dec 12, 2018 at 09:31:27AM +0000, Tian, Kevin wrote: > > > From: '[email protected]' > > > Sent: Monday, December 10, 2018 4:58 PM > > > These represent whether the device together with the IOMMU support > > > them, > > > basically whether these features are usable via the IOMMU-API. > > > > "device together with IOMMU" or just "IOMMU itself"? > > No, it should mean device together with IOMMU support it. It is a way > for users of the IOMMU-API to check whether they can successfully use > the aux-specific functions. > > > however there is a problem with aux. A device may implement both > > SR-IOV and Scalable IOV capabilities, but at any time only one of them > > can be enabled. Driver will provide interfaces for end user to choose. > > In such case we cannot assume that device-side Scalable-IOV can be > > always enabled while IOMMU is in scalable mode. > > > > It works better if we position those features just representing IOMMU > > support only. In that case, aux is related only to scalable mode of IOMMU > > itself, which is orthogonal to whether device side supports SIOV. > > Yeah, but we don't make that decision in the IOMMU code. Whether the > device exposes SR-IOV or PASID based isolation is decided in PCI code > based on user input (SR-IOV is also enabled in PCI code and IOMMU just > uses the new devices that appear). > > Only if the user enabled scalable mode on the device and the IOMMU > supports it too, the feature-check function returns true for the aux > feature. >
Then this is another proof for an enable/disable part in API. :-) Thanks kevin _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
