Jason Gunthorpe <jgg@xxxxxxxx> writes: > On Mon, Jul 28, 2025 at 07:21:47PM +0530, Aneesh Kumar K.V (Arm) wrote: >> With passthrough devices, we need to make sure private memory is >> allocated and assigned to the secure guest before we can issue the DMA. >> For ARM RMM, we only need to map and the secure SMMU management is >> internal to RMM. For shared IPA, vfio/iommufd DMA MAP/UNMAP interface >> does the equivalent > > I'm not really sure what this is about? It is about getting KVM to pin > all the memory and commit it to the RMM so it can be used for DMA? > That is correct. > > But it looks really strange to have an iommufd ioctl that just calls a > KVM function. Feeling this should be a KVM function, or a guestmfd > behavior?? > This functionality is equivalent to `IOMMU_IOAS_MAP`, but in the presence of firmware like RMM, we also need to supply the realm descriptor associated with the KVM instance. Initially, I attempted to handle this within the `map_pages` callback in `iommu_domain_ops`, but that path lacks any awareness of the associated KVM context, making it unsuitable for this purpose. > I was kind of thinking it would be nice to have a guestmemfd mode that > was "pinned", meaning the memory is allocated and remains almost > always mapped into the TSM's page tables automatically. VFIO using > guests would set things this way. > We need to allocate and free these pages dynamically as they are converted between private and shared states. -aneesh
