On Thu, Jul 31, 2025 at 10:09:36AM +0530, Aneesh Kumar K.V wrote: > 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? Sorry I was not clear, my point is that this patch adds support for vdev only to set the STE to bypass, which has the same effect on the device SID, so why add such complexity if the assignment will still work without it. AFAIK, the use of such feature will be to present an emualted SMMUv3 to the guest. Thanks, Mostafa > > > > > 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
