Mostafa Saleh <smostafa@xxxxxxxxxx> writes: > 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. > Can we do a S1 IPA -> PA and s2 bypass with viommu and vdevice? > > 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 -aneesh
