On Tue, Nov 08, 2022 at 03:28:31PM -0700, Alex Williamson wrote: > Perhaps this should have been obvious, but I'm realizing that > vfio-noiommu mode is completely missing without VFIO_CONTAINER, which > seems a barrier to deprecating VFIO_CONTAINER and perhaps makes it a Yes, it is the same as the allow_unsafe_interrupts - it is something that currently goes missing if you turn off VFIO_CONTAINER. This seems straightforward enough to resolve in a followup, we mostly just need someone with an existing no-iommu application to test compatability against. Keeping it working with the device cdev will also be a bit interesting. If you have or know about some application I can try to make a patch. > question whether IOMMUFD should really be taking over /dev/vfio/vfio. > No-iommu mode has users. I view VFIO_CONTAINER=n as a process. An aspiration we can work toward. At this point there are few places that might want to use it. Android perhaps, for example. It is also useful for testing. One of the main values is you can switch the options and feed the kernel into an existing test environment and see what happens. This is how we are able to quickly get s390 mdev testing, for instance. We are not going to get to a widely useful VFIO_CONTAINER=n if we don't have a target that people can test against and evaluate what compatability gaps may exist. So, everytime we find something like this - let's think about how can we make iommufd compatibility handle it and not jump straight to giving up :) I'm kind of thinking v6.4 might be a reasonable kernel target when we might have closed off enough things. Jason
