Message ID | d0cae90d891d93f4fb45731a23697c06581fe434.1729897278.git.nicolinc@nvidia.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE) | expand |
> From: Nicolin Chen <nicolinc@nvidia.com> > Sent: Saturday, October 26, 2024 7:51 AM > > @@ -302,7 +302,9 @@ iommufd_viommu_alloc_hwpt_nested(struct > iommufd_viommu *viommu, u32 flags, > } > hwpt->domain->owner = viommu->iommu_dev->ops; > > - if (WARN_ON_ONCE(hwpt->domain->type != > IOMMU_DOMAIN_NESTED)) { > + if (WARN_ON_ONCE(hwpt->domain->type != > IOMMU_DOMAIN_NESTED || > + (!viommu->ops->cache_invalidate && > + !hwpt->domain->ops->cache_invalidate_user))) { > rc = -EINVAL; > goto out_abort; > } According to patch5, cache invalidate in viommu only uses viommu->ops->cache_invalidate. Is here intended to allow nested hwpt created via viommu to still support the old method?
On Fri, Oct 25, 2024 at 04:50:33PM -0700, Nicolin Chen wrote: > A vIOMMU-based hwpt_nested requires a cache invalidation op too, either > using the one in iommu_domain_ops or the one in viommu_ops. Enforce that > upon the allocated hwpt_nested. > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > --- > drivers/iommu/iommufd/hw_pagetable.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Jason
On Tue, Oct 29, 2024 at 08:22:43AM +0000, Tian, Kevin wrote: > > From: Nicolin Chen <nicolinc@nvidia.com> > > Sent: Saturday, October 26, 2024 7:51 AM > > > > @@ -302,7 +302,9 @@ iommufd_viommu_alloc_hwpt_nested(struct > > iommufd_viommu *viommu, u32 flags, > > } > > hwpt->domain->owner = viommu->iommu_dev->ops; > > > > - if (WARN_ON_ONCE(hwpt->domain->type != > > IOMMU_DOMAIN_NESTED)) { > > + if (WARN_ON_ONCE(hwpt->domain->type != > > IOMMU_DOMAIN_NESTED || > > + (!viommu->ops->cache_invalidate && > > + !hwpt->domain->ops->cache_invalidate_user))) { > > rc = -EINVAL; > > goto out_abort; > > } > > According to patch5, cache invalidate in viommu only uses > viommu->ops->cache_invalidate. Is here intended to allow > nested hwpt created via viommu to still support the old > method? I think that is reasonable? Jason
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Wednesday, October 30, 2024 12:05 AM > > On Tue, Oct 29, 2024 at 08:22:43AM +0000, Tian, Kevin wrote: > > > From: Nicolin Chen <nicolinc@nvidia.com> > > > Sent: Saturday, October 26, 2024 7:51 AM > > > > > > @@ -302,7 +302,9 @@ iommufd_viommu_alloc_hwpt_nested(struct > > > iommufd_viommu *viommu, u32 flags, > > > } > > > hwpt->domain->owner = viommu->iommu_dev->ops; > > > > > > - if (WARN_ON_ONCE(hwpt->domain->type != > > > IOMMU_DOMAIN_NESTED)) { > > > + if (WARN_ON_ONCE(hwpt->domain->type != > > > IOMMU_DOMAIN_NESTED || > > > + (!viommu->ops->cache_invalidate && > > > + !hwpt->domain->ops->cache_invalidate_user))) { > > > rc = -EINVAL; > > > goto out_abort; > > > } > > > > According to patch5, cache invalidate in viommu only uses > > viommu->ops->cache_invalidate. Is here intended to allow > > nested hwpt created via viommu to still support the old > > method? > > I think that is reasonable? > Yes, just want to confirm. Reviewed-by: Kevin Tian <kevin.tian@intel.com>
diff --git a/drivers/iommu/iommufd/hw_pagetable.c b/drivers/iommu/iommufd/hw_pagetable.c index 1df5d40c93df..fd260a67b82c 100644 --- a/drivers/iommu/iommufd/hw_pagetable.c +++ b/drivers/iommu/iommufd/hw_pagetable.c @@ -302,7 +302,9 @@ iommufd_viommu_alloc_hwpt_nested(struct iommufd_viommu *viommu, u32 flags, } hwpt->domain->owner = viommu->iommu_dev->ops; - if (WARN_ON_ONCE(hwpt->domain->type != IOMMU_DOMAIN_NESTED)) { + if (WARN_ON_ONCE(hwpt->domain->type != IOMMU_DOMAIN_NESTED || + (!viommu->ops->cache_invalidate && + !hwpt->domain->ops->cache_invalidate_user))) { rc = -EINVAL; goto out_abort; }
A vIOMMU-based hwpt_nested requires a cache invalidation op too, either using the one in iommu_domain_ops or the one in viommu_ops. Enforce that upon the allocated hwpt_nested. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> --- drivers/iommu/iommufd/hw_pagetable.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)