Re: [PATCH] iommufd: fix returns ENOENT in iommufd_viommu_get_vdev_id()

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Aug 05, 2025 at 10:46:20AM +0800, Richard Gemego wrote:
> The motivation of this fix is when iommufd in selftests tested on RISC-V,
> 
> I found that `alloc_hwpt_nested` items are failed

That TEST_F is a non-viommu case, using the hwpt model, i.e.
mock_domain_alloc_nested() that does not set mock_viommu pointer,
leaving it a NULL value. Any vIOMMU/vdev specific thing should not
be invoked in this TEST_F.

> then I followed the
> function calling chains and found that in iommufd_viommu_get_vdev_id(),
> there is always not any vdev in viommu.

Then mock_domain_nop_attach() won't call iommufd_viommu_get_vdev_id
at all since the "new_viommu" there should be kept as NULL.

If you see this function is called for alloc_hwpt_nested TEST_F,
there must be something else going wrong. I would start to check
the mock_viommu pointer to see if it is set (and then by what).

> I wonder if it is because RISC-V
> does not support vIOMMU well, so that there isn't any any vdev in
> viommu, then iommufd_viommu_get_vdev_id() will always return
> -ENOENT. Have you ever tested it on RISC-V? Will viommu always have
> at least one vdev on ARM (since you have mentioned ARM in ea94b211c548
> patch series), so iommufd_viommu_get_vdev_id() can return 0 in iommufd
> selftest?

No. The underlying architecture should be independent, although the
kernel config file or compiler can be a factor.

Nicolin