[Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

[Jason Gunthorpe]

On Wed, Oct 26, 2022 at 03:24:42PM -0600, Alex Williamson wrote:
> On Tue, 25 Oct 2022 15:17:10 -0300
> Jason Gunthorpe <jgg at nvidia.com> wrote:
> 
> > This legacy module knob has become uAPI, when set on the vfio_iommu_type1
> > it disables some security protections in the iommu drivers. Move the
> > storage for this knob to vfio_main.c so that iommufd can access it too.
> 
> I don't really understand this, we're changing the behavior of the
> iommufd_device_attach() operation based on the modules options of
> vfio_iommu_type1, 

The specific reason it was done is that we had a misconfigured test VM
in the farm that needed it, and that VM has since been fixed. But it
did highlight we should try to preserve this in some way.

> which may not be loaded or even compiled into the
> kernel.  Our compatibility story falls apart when VFIO_CONTAINER is not
> set, iommufd sneaks in to usurp /dev/vfio/vfio, and the user's module
> options for type1 go unprocessed.

There are two aspects here, trying to preseve the
allow_unsafe_interrupts knob as it is already as some ABI in the best
way we can.

And the second is how do we make this work in the new world where
there may be no type 1 module at all. This patch is not trying to
address that topic. I am expecting a range of small adjustments before
VFIO_CONTAINER=n becomes really fully viable.

> I hate to suggest that type1 becomes a module that does nothing more
> than maintain consistency of this variable when the full type1 isn't
> available, but is that what we need to do?

It is one idea, it depends how literal you want to be on "module
parameters are ABI". IMHO it is a weak form of ABI and the need of
this paramter in particular is not that common in modern times, AFAIK.

So perhaps we just also expose it through vfio.ko and expect people to
migrate. That would give a window were both options are available.

Jason