On Fri, Mar 28, 2025 at 10:57:18AM +0530, Aneesh Kumar K.V wrote:
> > +int iommufd_vdevice_tsm_bind_ioctl(struct iommufd_ucmd *ucmd)
> > +{
> > + struct iommu_vdevice_tsm_bind *cmd = ucmd->cmd;
> > + struct iommufd_viommu *viommu;
> > + struct iommufd_vdevice *vdev;
> > + struct iommufd_device *idev;
> > + struct tsm_tdi *tdi;
> > + int rc = 0;
> > +
> > + viommu = iommufd_get_viommu(ucmd, cmd->viommu_id);
> > + if (IS_ERR(viommu))
> > + return PTR_ERR(viommu);
> >
>
> Would this require an IOMMU_HWPT_ALLOC_NEST_PARENT page table
> allocation?
Probably. That flag is what forces a S2 page table.
> How would this work in cases where there's no need to set up Stage 1
> IOMMU tables?
Either attach the raw HWPT of the IOMMU_HWPT_ALLOC_NEST_PARENT or:
> Alternatively, should we allocate an IOMMU_HWPT_ALLOC_NEST_PARENT with a
> Stage 1 disabled translation config? (In the ARM case, this could mean
> marking STE entries as Stage 1 bypass and Stage 2 translate.)
For arm you mean IOMMU_HWPT_DATA_ARM_SMMUV3.. But yes, this can work
too and is mandatory if you want the various viommu linked features to
work.
> Also, if a particular setup doesn't require creating IOMMU
> entries because the entire guest RAM is identity-mapped in the IOMMU, do
> we still need to make tsm_tdi_bind use this abstraction in iommufd?
Even if the viommu will not be exposed to the guest I'm expecting that
iommufd will have a viommu object, just not use various features. We
are using viommu as the handle for the KVM, vmid and other things that
are likely important here.
Jason
