On Thu, Nov 07, 2024 at 12:37:59PM +1100, Alexey Kardashevskiy wrote:
On 31/10/24 08:34, Nicolin Chen wrote:
+int iommufd_viommu_alloc_ioctl(struct iommufd_ucmd *ucmd) +{
struct iommu_viommu_alloc *cmd = ucmd->cmd;struct iommufd_hwpt_paging *hwpt_paging;struct iommufd_viommu *viommu;struct iommufd_device *idev;const struct iommu_ops *ops;int rc;if (cmd->flags || cmd->type == IOMMU_VIOMMU_TYPE_DEFAULT)return -EOPNOTSUPP;idev = iommufd_get_device(ucmd, cmd->dev_id);if (IS_ERR(idev))return PTR_ERR(idev);ops = dev_iommu_ops(idev->dev);if (!ops->viommu_alloc) {rc = -EOPNOTSUPP;goto out_put_idev;}hwpt_paging = iommufd_get_hwpt_paging(ucmd, cmd->hwpt_id);if (IS_ERR(hwpt_paging)) {rc = PTR_ERR(hwpt_paging);goto out_put_idev;}if (!hwpt_paging->nest_parent) {I am trying to use this for my so-called viommu which does not have this so this fails. My viommu is only visible to the VM via paravirt interface to populate sDTE (secure device table) so no viommu device in the guest or nested paging, nothing like this just yet.
Is there a writeup somewhere about possible uses of this IOMMU_HWPT_ALLOC_NEST_PARENT? I'd think one pass through device equals 1 IOAS, 1 HWPT, 1 domain, 1 viommu, even with guest visible vIOMMU but it is not the case, is it?
So far, the vIOMMU is exclusively designed for nesting, with the only use case of ARM SMMUv3. So, a nesting parent HWPT/domain is a must. So long as your use case is a good fit, we can drop this when adding support for your case, assuming there would be some new iommufd patches.
For nesting, there will be at least two HWPTs (i.e. two domains) for 2 stages. And stage-2 HWPT/domain is the nesting parent one.
btw is there a way to get a snapshot of all current objects in iommufd? They all use "dev_id" and not file descriptors so cannot look at /proc/><pid>/fd, and there is nothing in debugfs either.
I am not aware of anything like that. How would you like to use it if there was one?
For my current hack, I can pass IOMMU_HWPT_ALLOC_NEST_PARENT to QEMU's iommufd_backend_alloc_hwpt() but it is... meh. Thanks,
Again, assuming you have some other iommufd patches, I think you could have a small patch dropping this check -- we might need an additional flag or another HWPT type, but we can discuss later.
Thanks Nicolin