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.
> > /* So we need a iommu_aux_detach_all()? */
>
> for what scenario?
Maybe for detaching any PASID users from a device so that it can be
assigned to a VM as a whole. But I am not sure it is needed.
Regards,
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
