[PATCH v7 0/5] Define EINVAL as device/domain incompatibility

Nicolin Chen posted 5 patches 2 years ago
drivers/iommu/amd/iommu.c                   | 12 ++---------
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 +---------
drivers/iommu/arm/arm-smmu/arm-smmu.c       |  3 ---
drivers/iommu/arm/arm-smmu/qcom_iommu.c     |  7 +-----
drivers/iommu/fsl_pamu.c                    |  2 +-
drivers/iommu/fsl_pamu_domain.c             |  4 ++--
drivers/iommu/intel/iommu.c                 | 10 +++------
drivers/iommu/intel/pasid.c                 |  6 ++++--
drivers/iommu/iommu.c                       | 24 +++++++++++++++++++++
drivers/iommu/ipmmu-vmsa.c                  |  2 --
drivers/iommu/mtk_iommu.c                   |  4 ++--
drivers/iommu/omap-iommu.c                  |  6 +++---
drivers/iommu/sprd-iommu.c                  |  4 +---
drivers/iommu/tegra-gart.c                  |  2 +-
drivers/iommu/virtio-iommu.c                |  7 +++---
include/linux/iommu.h                       | 12 +++++++++++
16 files changed, 60 insertions(+), 56 deletions(-)
[PATCH v7 0/5] Define EINVAL as device/domain incompatibility
Posted by Nicolin Chen 2 years ago
This series is to replace the previous EMEDIUMTYPE patch in a VFIO series:
https://lore.kernel.org/kvm/Yxnt9uQTmbqul5lf@8bytes.org/

The purpose is to regulate all existing ->attach_dev callback functions to
use EINVAL exclusively for an incompatibility error between a device and a
domain. This allows VFIO and IOMMUFD to detect such a soft error, and then
try a different domain with the same device.

Among all the patches, the first two are preparatory changes. And then one
patch to update kdocs and another three patches for the enforcement effort.

Although it might be ideal to merge the previous VFIO series together with
this series, given the number of new changes, the review in the IOMMU list
might need a couple of rounds to finalize. Also, considering that v6.0 is
at rc5 now, perhaps we could merge this IOMMU series and the VFIO one in
different cycles to avoid merge conflicts. If there's less concern for it,
I can respin the finalized version of this series with the previous VFIO
one to merge together into the VFIO tree.

This series is also available on Github:
https://github.com/nicolinc/iommufd/commits/iommu_attach_dev-v7

Changelog
v7/resend:
 * Rebased on v6.1-rc1
v6: https://lore.kernel.org/linux-iommu/cover.1663899032.git.nicolinc@nvidia.com/
 * Added "Reviewed-by" from Jason to all the changes
 * Added "Reviewed-by" from Yong to the mtk_iommu change
 * Dropped the msm patch as it needs a bigger change to fix
v5: https://lore.kernel.org/linux-iommu/cover.1663836372.git.nicolinc@nvidia.com/
 * Updated kdocs to correct "attach" narratives
 * Updated kdocs to be more concise and accurate
 * Added "Reviewed-by" from Kevin to most of changes
 * Added "Reviewed-by" from Baolu to the intel_iommu changes
 * Added "Reviewed-by" from Jean to the virtio-iommu changes
v4: https://lore.kernel.org/linux-iommu/cover.1663744983.git.nicolinc@nvidia.com/
 * Refined kdocs with Kevin's input
 * Fixed an EINVAL conversion in the intel_iommu driver
 * Added missing error-out routines in the msm_iommu driver
 * Added a missing EINVAL conversion in the virtio-iommu driver
 * Updated commit message and added "Reviewed-by" from Kevin to the last patch
v3: https://lore.kernel.org/linux-iommu/cover.1663227492.git.nicolinc@nvidia.com/
 * Added "Reviewed-by" from Vasant to the AMD patch
 * Dropped all unnecessary errno enforcement patches
 * Updated kdocs and brought back the kdocs for the helpers
 * Added a separate patch to propagate "ret" for potential EINVALs
 * Converted to ENODEV those existing EINVAL places that are device-specific
v2: https://lore.kernel.org/linux-iommu/20220914051234.10006-1-nicolinc@nvidia.com/
 * Fixed kdocs format
 * Grouped with the virtio patch from Jean (with a small change)
 * Separated previous ENODEV and EINVAL changes to per-driver ones
 * Redone some of the changes to have explicit return values in the
   ->attach_dev() callback functions or their direct sub-functions.
v1: https://lore.kernel.org/linux-iommu/20220913082448.31120-1-nicolinc@nvidia.com/

Thanks!

Nicolin Chen (5):
  iommu/amd: Drop unnecessary checks in amd_iommu_attach_device()
  iommu: Add return value rules to attach_dev op and APIs
  iommu: Regulate EINVAL in ->attach_dev callback functions
  iommu: Use EINVAL for incompatible device/domain in ->attach_dev
  iommu: Propagate return value in ->attach_dev callback functions

 drivers/iommu/amd/iommu.c                   | 12 ++---------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 +---------
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |  3 ---
 drivers/iommu/arm/arm-smmu/qcom_iommu.c     |  7 +-----
 drivers/iommu/fsl_pamu.c                    |  2 +-
 drivers/iommu/fsl_pamu_domain.c             |  4 ++--
 drivers/iommu/intel/iommu.c                 | 10 +++------
 drivers/iommu/intel/pasid.c                 |  6 ++++--
 drivers/iommu/iommu.c                       | 24 +++++++++++++++++++++
 drivers/iommu/ipmmu-vmsa.c                  |  2 --
 drivers/iommu/mtk_iommu.c                   |  4 ++--
 drivers/iommu/omap-iommu.c                  |  6 +++---
 drivers/iommu/sprd-iommu.c                  |  4 +---
 drivers/iommu/tegra-gart.c                  |  2 +-
 drivers/iommu/virtio-iommu.c                |  7 +++---
 include/linux/iommu.h                       | 12 +++++++++++
 16 files changed, 60 insertions(+), 56 deletions(-)

-- 
2.17.1
Re: [PATCH v7 0/5] Define EINVAL as device/domain incompatibility
Posted by Jason Gunthorpe 2 years ago
On Mon, Oct 17, 2022 at 04:00:29PM -0700, Nicolin Chen wrote:
> This series is to replace the previous EMEDIUMTYPE patch in a VFIO series:
> https://lore.kernel.org/kvm/Yxnt9uQTmbqul5lf@8bytes.org/
> 
> The purpose is to regulate all existing ->attach_dev callback functions to
> use EINVAL exclusively for an incompatibility error between a device and a
> domain. This allows VFIO and IOMMUFD to detect such a soft error, and then
> try a different domain with the same device.
> 
> Among all the patches, the first two are preparatory changes. And then one
> patch to update kdocs and another three patches for the enforcement effort.
> 
> Although it might be ideal to merge the previous VFIO series together with
> this series, given the number of new changes, the review in the IOMMU list
> might need a couple of rounds to finalize. Also, considering that v6.0 is
> at rc5 now, perhaps we could merge this IOMMU series and the VFIO one in
> different cycles to avoid merge conflicts. If there's less concern for it,
> I can respin the finalized version of this series with the previous VFIO
> one to merge together into the VFIO tree.
> 
> This series is also available on Github:
> https://github.com/nicolinc/iommufd/commits/iommu_attach_dev-v7

Since it didn't make v6.1-rc1, I'd like this on a PR as we have two
trees that will need it now.

Joerg I can make this into a formal signed PR if that is how you'd
like things?

Thanks,
Jason