> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, November 8, 2022 8:10 AM > > On Mon, Nov 07, 2022 at 11:53:24PM +0000, Tian, Kevin wrote: > > > Other than that, userspace can change the IOAS it wants freely, there > > > is no harm to the kernel and it may even be useful. > > > > it allows devices SET_CONTAINER to an same iommufd attached to > different > > IOAS's if IOAS_SET comes in the middle. Is it desired? > > Sure, if userspace does crazy things then userspace gets to keep all > the pieces - it doesn't harm the kernel. > > The IOAS is bound during get_device, and that is one of the key > conceptual things we changed with iommufd. > what we changed is the timing of claiming DMA ownership (from SET_CONTAINER to GET_DEVICE_FD). this is fine. But adding an interface to allow the conceptual 'container' tied to multiple IOAS's is kind of overengineering IMHO. yes no hard to the kernel but also no benefit to user. It's simpler to constrain the compat layer based on what vfio legacy has today and then position all new/fancy usages with the new cdev.
