On Thu, Oct 17, 2024 at 01:51:51PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:05AM -0700, Nicolin Chen wrote:
> > With a viommu object wrapping a potentially shareable S2 domain, a nested
> > domain should be allocated by associating to a viommu instead.
> >
> > For drivers without a viommu support, keep the parent domain input, which
> > should be just viommu->hwpt->common.domain otherwise.
> >
> > Signed-off-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> > ---
> > include/linux/iommu.h | 1 +
> > drivers/iommu/amd/iommu.c | 1 +
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 +
> > drivers/iommu/intel/iommu.c | 1 +
> > drivers/iommu/iommufd/hw_pagetable.c | 5 +++--
> > drivers/iommu/iommufd/selftest.c | 1 +
> > 6 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 3a50f57b0861..9105478bdbcd 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -573,6 +573,7 @@ struct iommu_ops {
> > struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
> > struct iommu_domain *(*domain_alloc_user)(
> > struct device *dev, u32 flags, struct iommu_domain *parent,
> > + struct iommufd_viommu *viommu,
> > const struct iommu_user_data *user_data);
>
> This re-enforces my feeling we should have made a
> domain_alloc_nested()..
That could make these changes slightly cleaner. Maybe adding a
small series prior to your initial nesting, and get it merged
quickly?
Assuming these nesting series can make it to this cycle, that
would be in the late rc stage anyway.
> > struct iommu_domain *(*domain_alloc_paging)(struct device *dev);
> > struct iommu_domain *(*domain_alloc_sva)(struct device *dev,
> > diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> > index 8364cd6fa47d..3100ddcaf62e 100644
> > --- a/drivers/iommu/amd/iommu.c
> > +++ b/drivers/iommu/amd/iommu.c
> > @@ -2394,6 +2394,7 @@ static struct iommu_domain *amd_iommu_domain_alloc(unsigned int type)
> > static struct iommu_domain *
> > amd_iommu_domain_alloc_user(struct device *dev, u32 flags,
> > struct iommu_domain *parent,
> > + struct iommufd_viommu *viommu,
> > const struct iommu_user_data *user_data)
> >
> > {
>
> Do these all need to check for NULL viommu now too? Something is
> needed at least, only valid viommus should be accepted here. Like you
> can't pass an ARM viommu to AMD or something silly.
These drivers don't have iommu_ops->viommu_alloc, so a viommu
(!TYPE_DEFAULT) object won't reach to here.
Perhaps we should block IOMMU_VIOMMU_TYPE_DEFAULT allocations
if !iommu_ops->default_viommu_ops, in the core.
> Should drivers accept the default viommu?
Yes, driver can use default_viommu_ops.
Thanks
Nicolin
