On 20/10/2026 16:13, Alex Williamson wrote: > On Tue, 20 Oct 2026 16:06:37 +0100 > Ryan Roberts <[email protected]> wrote: > >> 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? > > The cdev is not unlocked to actually access the device until it's bound > to iommufd. Thanks,
Ahh - got it! Thanks! > > Alex
