On Sat, Nov 02, 2024 at 10:22:54AM +0000, Gowans, James wrote: > Yes, I think the guidance was to bind a device to iommufd in noiommu > mode. It does seem a bit weird to use iommufd with noiommu, but we > agreed it's the best/simplest way to get the functionality. noiommu should still have an ioas and still have kernel managed page pinning. My remark to bring it to iommufd was to also make it a fully architected feature and stop relying on mprotect and /proc/ tricks. > Then as you suggest below the IOMMUFD_OBJ_DEVICE would be serialised > too in some way, probably by iommufd telling the PCI layer that this > device must be persistent and hence not to re-probe it on kexec. Presumably VFIO would be doing some/most of this part since it is the driver that will be binding? > It's all a bit hand wavy at the moment, but something along those lines > probably makes sense. I need to work on rev2 of this RFC as per Jason's > feedback in the other thread. Rev2 will make the restore path more > userspace driven, with fresh iommufd and pgtables objects being created > and then atomically swapped over too. I'll also get the PCI layer > involved with rev2. Once that's out (it'll be a few weeks as I'm on > leave) then let's take a look at how the noiommu device persistence case > would fit in. In a certain sense it would be nice to see the noiommu flow as it breaks apart the problem into the first dependency: How to get the device handed across the kexec and safely land back in VFIO, and only VFIO's hands. Preserving the iommu HW configuration is an incremental step built on that base line. Also, FWIW, this needs to follow good open source practices - we need an open userspace for the feature and the kernel stuff should be merged in a logical order. Jason
