On Wed, Jul 30, 2025 at 01:43:21PM +0530, Aneesh Kumar K.V wrote: > 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? I believe that's correct, my question was why does it matter if the config is S1 bypass + S2 IPA -> PA as opposed to before this patch where it would be S1 IPA -> PA and s2 bypass. As in this patch we manage the STE but set in bypass, so we don't actually use nesting. > > > > > 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`. Makes sense. Thanks, Mostafa > > The main requirement here is the ability to create a `vdevice` and > use that in the VFIO setup flow. > > -aneesh
