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 vfio-next and tested with s390x-pci (zdev-kvm series) and vfio-ap (GVT changes are compile-tested only) Changes for v3: - merge branches under if (device->open_count == 1) (Kevin) - move device->open_count-- out from group_rwsem (Kevin) - drop null KVM check (Christoph) - remove extra kvm_{get,put}_kvm from vfio_ap_ops, it was already getting a reference (Jason) - Add comment about kvm reference in vfio.h (Jason) - Return -EINVAL if !kvm for vfio-ap (Tony) 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 | 35 ++--------- drivers/s390/crypto/vfio_ap_private.h | 3 - drivers/vfio/vfio.c | 83 ++++++++++----------------- include/linux/vfio.h | 6 +- 7 files changed, 57 insertions(+), 159 deletions(-) -- 2.27.0
