As discussed in this thread: https://lore.kernel.org/kvm/20220516172734.GE1343366@xxxxxxxxxx/ Let's remove VFIO_GROUP_NOTIFY_SET_KVM and instead assume the association has already been established prior to device_open. For the types today that need a KVM (GVT, vfio-ap) these will fail if a KVM is not found. Looking ahead, vfio-pci-zdev will optionally want the KVM association (enable hardware assists) but it will not be a hard requirement (still want to allow other, non-KVM userspace usage). This is built on top of Jason's group locking series: https://github.com/jgunthorpe/linux/commits/vfio_group_locking And tested with s390x-pci (zdev-kvm series) and vfio-ap (GVT changes are compile-tested only) Changes for v2: - gvt no longer needs release_work, get rid of it (Christoph) - a few compile fixes for gvt - update commit to mention fixes gvt oops (Jason) - s/down_write/down_read/ in a few spots (Jason) - avoid kvm build dependency by holding group read lock over device open/close and put the onus on the driver to obtain a reference if it will actually use the kvm pointer. Document the requirement, use lockdep_assert to ensure lock is held during register_notifer; today all callers are from driver open_device. Matthew Rosato (1): vfio: remove VFIO_GROUP_NOTIFY_SET_KVM drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/gvt.h | 3 - drivers/gpu/drm/i915/gvt/kvmgt.c | 82 ++++++--------------------- drivers/s390/crypto/vfio_ap_ops.c | 38 ++++--------- drivers/s390/crypto/vfio_ap_private.h | 3 - drivers/vfio/vfio.c | 75 ++++++++---------------- include/linux/vfio.h | 5 +- 7 files changed, 56 insertions(+), 154 deletions(-) -- 2.27.0
