s390/vfio-ap: introduce new mutex to control access to the KVM pointer

The vfio_ap device driver registers for notification when the pointer to
the KVM object for a guest is set. Recall that the KVM lock (kvm->lock)
mutex must be taken outside of the matrix_dev->lock mutex to prevent the
reporting by lockdep of a circular locking dependency (a.k.a., a lockdep
splat):

* see commit 1ce1560c318d ("Fix circular lockdep when setting/clearing
  crypto masks")

* see commit c4e5109e5e8c ("replace open coded locks for
  VFIO_GROUP_NOTIFY_SET_KVM notification")

With the introduction of support for hot plugging/unplugging AP devices
passed through to a KVM guest, a new guests_lock mutex is introduced to
ensure the proper locking order is maintained:

struct ap_matrix_dev {
        ...
        struct mutex guests_lock;
       ...
}

The matrix_dev->guests_lock controls access to the matrix_mdev instances
that hold the state for AP devices that have been passed through to a
KVM guest. This lock must be held to control access to the KVM pointer
(matrix_mdev->kvm) while the vfio_ap device driver is using it to
plug/unplug AP devices passed through to the KVM guest.

Keep in mind, the proper locking order must be maintained whenever
dynamically updating a KVM guest's APCB to plug/unplug adapters, domains
and control domains:

    1. matrix_dev->guests_lock: required to use the KVM pointer - stored in
       a struct ap_matrix_mdev instance - to update a KVM guest's APCB

    2. matrix_mdev->kvm->lock: required to update a guest's APCB

    3. matrix_dev->mdevs_lock: required to access data stored in a
       struct ap_matrix_mdev instance.

Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>

diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index ed162732b13952b8f801957f2b54f9afa2d15716..db8ca7bb3696ecae75549b74e921a255959c5f5a 100644 (file)
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -100,6 +100,7 @@ static int vfio_ap_matrix_dev_create(void)
 
        mutex_init(&matrix_dev->mdevs_lock);
        INIT_LIST_HEAD(&matrix_dev->mdev_list);
+       mutex_init(&matrix_dev->guests_lock);
 
        dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME);
        matrix_dev->device.parent = root_device;

diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index cb4a626b4b0fcc3ddc3a9dc89e4e04b170b29a90..97734b599583ad12c1d9f465ab0c1b8d61eac633 100644 (file)
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -39,6 +39,11 @@
  *             single ap_matrix_mdev device. It's quite coarse but we don't
  *             expect much contention.
  * @vfio_ap_drv: the vfio_ap device driver
+ * @guests_lock: mutex for controlling access to a guest that is using AP
+ *              devices passed through by the vfio_ap device driver. This lock
+ *              will be taken when the AP devices are plugged into or unplugged
+ *              from a guest, and when an ap_matrix_mdev device is added to or
+ *              removed from @mdev_list or the list is iterated.
  */
 struct ap_matrix_dev {
        struct device device;
@@ -47,6 +52,7 @@ struct ap_matrix_dev {
        struct list_head mdev_list;
        struct mutex mdevs_lock; /* serializes access to each ap_matrix_mdev */
        struct ap_driver  *vfio_ap_drv;
+       struct mutex guests_lock; /* serializes access to each KVM guest */
 };
 
 extern struct ap_matrix_dev *matrix_dev;