Hi,
On 09/13/2018 01:54 AM, Jean-Philippe Brucker wrote:
On 12/09/2018 03:42, Lu Baolu wrote:
Hi,
On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote:
Hi,
On 30/08/2018 05:09, Lu Baolu wrote:
Below APIs are introduced in the IOMMU glue for device drivers to use
the finer granularity translation.
* iommu_capable(IOMMU_CAP_AUX_DOMAIN)
- Represents the ability for supporting multiple domains per device
(a.k.a. finer granularity translations) of the IOMMU hardware.
iommu_capable() cannot represent hardware capabilities, we need
something else for systems with multiple IOMMUs that have different
caps. How about iommu_domain_get_attr on the device's domain instead?
Domain is not a good choice for per iommu cap query. A domain might be
attached to devices belonging to different iommu's.
How about an API with device structure as parameter? A device always
belongs to a specific iommu. This API is supposed to be used the
device driver.
Ah right, domain attributes won't work. Your suggestion seems more
suitable, but maybe users can simply try to enable auxiliary domains
first, and conclude that the IOMMU doesn't support it if it returns an error
Some driver might want to check whether hardware supports AUX_DOMAIN
during the driver probe stage, but doesn't want to enable AUX_DOMAIN
at that time. One reasonable use case is driver check AUX_DOMAIN cap
during driver probe and expose different sysfs nodes according to
whether AUX_DOMAIN is support or not, then AUX_DOMAIN is enabled or
disabled during run time through a sysfs node. With this consideration,
we still need a API to check cap.
How about
* iommu_check_aux_domain(struct device *dev)
- Check whether the iommu driver supports multiple domains on @dev.
Best regards,
Lu Baolu
