> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, November 9, 2022 9:11 PM > > > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make > > more sense to remove this patch from this series i.e. let it buried in > > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if > > no consensus can be made quickly at this point. > > This is worse, it would make iommufd completely unusable in situations > where we need allow_unsafe_interrupts. If we belive that is important > we should keep this patch so existing systems on kernels with > VFIO_CONTAINER=y continue to work after libvirt/qemu are upgraded to > iommufd. > You are right. I kept a wrong thought that v2 has moved the option into vfio_main which is what I commented to hold before consensus was made. btw is it a good tradeoff by making vfio-compat as a module to carry this option? anyway it's not necessarily to be in iommufd core when VFIO=n.
