Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

["'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'" <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>]

Hi Kevin,

On Wed, Dec 12, 2018 at 09:31:27AM +0000, Tian, Kevin wrote:
> > From: 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'
> > 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.

Regards,

	Joerg