Mostafa Saleh <smostafa@xxxxxxxxxx> writes: > On Tue, Jul 29, 2025 at 10:49:31AM +0530, Aneesh Kumar K.V wrote: >> Mostafa Saleh <smostafa@xxxxxxxxxx> writes: >> >> > On Sun, May 25, 2025 at 01:19:15PM +0530, Aneesh Kumar K.V (Arm) wrote: >> >> This also allocates a stage1 bypass and stage2 translate table. >> > >> > So this makes IOMMUFD only working with SMMUv3? >> > >> > I don’t understand what is the point of this configuration? It seems to add >> > extra complexity and extra hw constraints and no extra value. >> > >> > Not related to this patch, do you have plans to add some of the other iommufd >> > features, I think things such as page faults might be useful? >> > >> >> The primary goal of adding viommu/vdevice support is to enable kvmtool >> to serve as the VMM for ARM CCA secure device development. This requires >> a viommu implementation so that a KVM file descriptor can be associated >> with the corresponding viommu. >> >> The full set of related patches is available here: >> https://gitlab.arm.com/linux-arm/kvmtool-cca/-/tree/cca/tdisp-upstream-post-v1 > > I see, but I don't understand why we need a nested setup in that case? > How would having bypassed stage-1 change things? > I might be misunderstanding the viommu/vdevice setup, but I was under the impression that it requires an `IOMMU_HWPT_ALLOC_NEST_PARENT`-type HWPT allocation. Based on that, I expected the viommu allocation to look something like this: alloc_viommu.size = sizeof(alloc_viommu); alloc_viommu.flags = IOMMU_VIOMMU_KVM_FD; alloc_viommu.type = IOMMU_VIOMMU_TYPE_ARM_SMMUV3; alloc_viommu.dev_id = vdev->bound_devid; alloc_viommu.hwpt_id = alloc_hwpt.out_hwpt_id; alloc_viommu.kvm_vm_fd = kvm->vm_fd; if (ioctl(iommu_fd, IOMMU_VIOMMU_ALLOC, &alloc_viommu)) { Could you clarify if this is the correct usage pattern, or whether a different HWPT setup is expected here? > > Also, In case we do something like this, I'd suggest to make it clear > for the command line that this is SMMUv3/CCA only, and maybe move > some of the code to arm64/ > My intent wasn't to make this SMMUv3-specific. Ideally, we could make the IOMMU type a runtime option in `lkvm`. The main requirement here is the ability to create a `vdevice` and use that in the VFIO setup flow. -aneesh
