On 20/10/2026 15:09, Jason Gunthorpe wrote: > On Tue, Oct 20, 2026 at 12:51:26PM +0100, Ryan Roberts wrote: >>> However.. you still have to affirm which single mm is the mm that the >>> device is going to be doing DMA against. The process the opens the fd >>> should not be forced to be the mm that it gets linked to. >> >> What is the mm representing here? Ultimately we want to install the KVM >> instance's stage2 pgtables and (pinned) VMID. We currently get that via the >> bound KVM instance (which looks like it still works using the cdev >> interface?) >> >> The guest will then install the stage1 pgtables and (pinned) ASID associated >> with the relevant (guest) mm_struct. >> >> Do we _need_ an mm association in the host? > > Ah.. I see, I didn't quite follow that. OK.. Ah everyone else doing > this is using iommufd with a viommu to establish their connection > between device an KVM. eg Jacob Pan's series. That's a probably a > better idea to stay aligned with the common path. Though your reasons > are a little different..
Just to check, you're referring to [1]? I was under the impression that I could open the VFIO device through the cdev interface, then bind it to the KVM instance via KVM_DEV_VFIO_FILE_ADD... Why do I need an iommufd at all? [1] https://lore.kernel.org/all/[email protected]/#t Thanks, Ryan > > If you manage to get pinned VMID out of KVM then we can implement SMMU > BTM as well! > > Jason
