Hi Jason,
On 15/10/2026 17:44, Jason Gunthorpe wrote: > On Thu, Oct 15, 2026 at 03:25:46PM +0100, Ryan Roberts wrote: >> From: Jean-Philippe Brucker <[email protected]> >> >> Support devices that are attached to a CPU and perform DMA through a >> MMU. They do not have an IOMMU and do not use a VFIO container. >> The VMM needs device-specific knowledge in order to create a virtual >> device (device tree, ACPI tables), so it also knows not to allocate a >> container. > > I'm not so excited to see new things built on top of the group > interface. > > Maybe in this case you just don't have to do a bind operation on the > cdev to an iommufd? That feels kind of natural if you don't use a > iommufd Yes, that makes sense. I don't know enough to know what actually needs to change to make this work, but will look in this direction. > > 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? Thanks, Ryan > > From that perspective maybe you should create an iommufd and a special > "SVA" IOAS that it can attach to. This is more complicated but it > makes the mm linkage and blocking beahvior explicit and controlled by > userspace. > > Jason
