From: Tony Krowiak <akrowiak@linux.ibm.com>
To: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Cc: jjherne@linux.ibm.com, freude@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com,
mjrosato@linux.ibm.com, pasic@linux.ibm.com,
alex.williamson@redhat.com, kwankhede@nvidia.com,
fiuczy@linux.ibm.com, Tony Krowiak <akrowiak@linux.ibm.com>
Subject: [PATCH v17 08/15] s390/vfio-ap: keep track of active guests
Date: Thu, 21 Oct 2021 11:23:25 -0400 [thread overview]
Message-ID: <20211021152332.70455-9-akrowiak@linux.ibm.com> (raw)
In-Reply-To: <20211021152332.70455-1-akrowiak@linux.ibm.com>
The vfio_ap device driver registers for notification when the pointer to
the KVM object for a guest is set. Let's store the KVM pointer as well as
the pointer to the mediated device when the KVM pointer is set.
The reason for storing the KVM and mediated device pointers is to
facilitate hot plug/unplug of AP queues for a KVM guest when a queue device
is probed or removed. When a guest's APCB is hot plugged into the guest,
the kvm->lock must be taken prior to taking the matrix_dev->lock, or there
is potential for a lockdep splat (see below). Unfortunately, when a queue
is probed or removed, we have no idea whether it is assigned to a guest or
which KVM object is associated with the guest. If we take the
matrix_dev->lock to determine whether the APQN is assigned to a running
guest then subsequently take the kvm->lock, in certain situations that will
result in a lockdep splat:
* see commit 0cc00c8d4050 ("Fix circular lockdep when setting/clearing
crypto masks")
* see commit 86956e70761b ("replace open coded locks for
VFIO_GROUP_NOTIFY_SET_KVM notification")
The reason a lockdep splat can occur has to do with the fact that the
kvm->lock has to be taken before the vcpu->lock; so, for example, when a
secure execution guest is started, you may end up with the following
scenario:
Interception of PQAP(AQIC) instruction executed on the guest:
------------------------------------------------------------
handle_pqap: matrix_dev->lock
kvm_vcpu_ioctl: vcpu_mutex
Start of secure execution guest:
-------------------------------
kvm_s390_cpus_to_pv: vcpu->mutex
kvm_arch_vm_ioctl: kvm->lock
Queue is unbound from vfio_ap device driver:
-------------------------------------------
kvm->lock
vfio_ap_mdev_remove_queue: matrix_dev->lock
This patch introduces a new ap_guest structure into which the pointers to
the kvm and matrix_mdev can be stored. It also introduces two new fields
in the struct ap_matrix_dev:
struct ap_matrix_dev {
...
struct rw_semaphore guests_lock;
struct list_head guests;
...
}
The 'guests_lock' field is a r/w semaphore to control access to the
'guests' field. The 'guests' field is a list of ap_guest
structures containing the KVM and matrix_mdev pointers for each active
guest. An ap_guest structure will be stored into the list whenever the
vfio_ap device driver is notified that the KVM pointer has been set and
removed when notified that the KVM pointer has been cleared.
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
---
drivers/s390/crypto/vfio_ap_drv.c | 2 ++
drivers/s390/crypto/vfio_ap_ops.c | 44 +++++++++++++++++++++++++--
drivers/s390/crypto/vfio_ap_private.h | 10 ++++++
3 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index 5255e338591d..1d1746fe50ea 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -98,6 +98,8 @@ static int vfio_ap_matrix_dev_create(void)
mutex_init(&matrix_dev->lock);
INIT_LIST_HEAD(&matrix_dev->mdev_list);
+ init_rwsem(&matrix_dev->guests_lock);
+ INIT_LIST_HEAD(&matrix_dev->guests);
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_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 6b40db6dab3c..a2875cf79091 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1086,6 +1086,20 @@ static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {
NULL
};
+static int vfio_ap_mdev_create_guest(struct kvm *kvm,
+ struct ap_matrix_mdev *matrix_mdev)
+{
+ struct ap_guest *guest;
+
+ guest = kzalloc(sizeof(*guest), GFP_KERNEL);
+ if (!guest)
+ return -ENOMEM;
+
+ list_add(&guest->node, &matrix_dev->guests);
+
+ return 0;
+}
+
/**
* vfio_ap_mdev_set_kvm - sets all data for @matrix_mdev that are needed
* to manage AP resources for the guest whose state is represented by @kvm
@@ -1106,16 +1120,23 @@ static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {
static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,
struct kvm *kvm)
{
+ int ret;
struct ap_matrix_mdev *m;
if (kvm->arch.crypto.crycbd) {
+ down_write(&matrix_dev->guests_lock);
+ ret = vfio_ap_mdev_create_guest(kvm, matrix_mdev);
+ if (WARN_ON(ret))
+ return ret;
+
mutex_lock(&kvm->lock);
mutex_lock(&matrix_dev->lock);
list_for_each_entry(m, &matrix_dev->mdev_list, node) {
if (m != matrix_mdev && m->kvm == kvm) {
- mutex_unlock(&kvm->lock);
mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&kvm->lock);
+ up_write(&matrix_dev->guests_lock);
return -EPERM;
}
}
@@ -1127,8 +1148,9 @@ static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,
matrix_mdev->shadow_apcb.aqm,
matrix_mdev->shadow_apcb.adm);
- mutex_unlock(&kvm->lock);
mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&kvm->lock);
+ up_write(&matrix_dev->guests_lock);
}
return 0;
@@ -1164,6 +1186,18 @@ static int vfio_ap_mdev_iommu_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static void vfio_ap_mdev_remove_guest(struct kvm *kvm)
+{
+ struct ap_guest *guest, *tmp;
+
+ list_for_each_entry_safe(guest, tmp, &matrix_dev->guests, node) {
+ if (guest->kvm == kvm) {
+ list_del(&guest->node);
+ break;
+ }
+ }
+}
+
/**
* vfio_ap_mdev_unset_kvm - performs clean-up of resources no longer needed
* by @matrix_mdev.
@@ -1182,6 +1216,9 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev,
struct kvm *kvm)
{
if (kvm && kvm->arch.crypto.crycbd) {
+ down_write(&matrix_dev->guests_lock);
+ vfio_ap_mdev_remove_guest(kvm);
+
mutex_lock(&kvm->lock);
mutex_lock(&matrix_dev->lock);
@@ -1191,8 +1228,9 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev,
kvm->arch.crypto.data = NULL;
matrix_mdev->kvm = NULL;
- mutex_unlock(&kvm->lock);
mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&kvm->lock);
+ up_write(&matrix_dev->guests_lock);
}
}
diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index 6dc0ebbf7a06..6d28b287d7bf 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -26,6 +26,11 @@
#define VFIO_AP_MODULE_NAME "vfio_ap"
#define VFIO_AP_DRV_NAME "vfio_ap"
+struct ap_guest {
+ struct kvm *kvm;
+ struct list_head node;
+};
+
/**
* struct ap_matrix_dev - Contains the data for the matrix device.
*
@@ -39,6 +44,9 @@
* 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: r/w semaphore for protecting access to @guests
+ * @guests: list of guests (struct ap_guest) using AP devices bound to the
+ * vfio_ap device driver.
*/
struct ap_matrix_dev {
struct device device;
@@ -47,6 +55,8 @@ struct ap_matrix_dev {
struct list_head mdev_list;
struct mutex lock;
struct ap_driver *vfio_ap_drv;
+ struct rw_semaphore guests_lock;
+ struct list_head guests;
};
extern struct ap_matrix_dev *matrix_dev;
--
2.31.1
next prev parent reply other threads:[~2021-10-21 15:24 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 15:23 [PATCH v17 00/15] s390/vfio-ap: dynamic configuration support Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 01/15] s390/vfio-ap: Set pqap hook when vfio_ap module is loaded Tony Krowiak
2021-12-27 8:21 ` Halil Pasic
2022-01-11 21:13 ` Tony Krowiak
2022-01-04 16:22 ` Jason J. Herne
2022-01-11 17:29 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 02/15] s390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2021-12-27 8:25 ` Halil Pasic
2022-01-11 17:32 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 03/15] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 04/15] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 05/15] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 06/15] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev Tony Krowiak
2021-12-27 8:53 ` Halil Pasic
2022-01-11 21:19 ` Tony Krowiak
2022-01-12 11:52 ` Halil Pasic
2022-01-15 0:31 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 07/15] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2021-12-27 9:06 ` Halil Pasic
2021-10-21 15:23 ` Tony Krowiak [this message]
2021-12-30 2:04 ` [PATCH v17 08/15] s390/vfio-ap: keep track of active guests Halil Pasic
2022-01-11 21:27 ` Tony Krowiak
2021-12-30 3:33 ` Halil Pasic
2022-01-11 21:58 ` Tony Krowiak
2022-01-11 22:19 ` Tony Krowiak
2022-01-12 14:25 ` Halil Pasic
2022-01-15 0:29 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 09/15] s390/vfio-ap: allow hot plug/unplug of AP resources using mdev device Tony Krowiak
2022-01-09 21:36 ` Halil Pasic
2022-01-11 22:42 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 10/15] s390/vfio-ap: reset queues after adapter/domain unassignment Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 11/15] s390/ap: driver callback to indicate resource in use Tony Krowiak
2021-11-04 11:27 ` Harald Freudenberger
2021-11-04 15:48 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 12/15] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 13/15] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 14/15] s390/ap: notify drivers on config changed and scan complete callbacks Tony Krowiak
2021-11-04 12:06 ` Harald Freudenberger
2021-11-04 15:50 ` Tony Krowiak
2021-11-05 8:23 ` Harald Freudenberger
2021-11-05 13:15 ` Harald Freudenberger
2021-11-08 14:27 ` Tony Krowiak
2021-11-08 14:26 ` Tony Krowiak
2022-02-04 10:43 ` Halil Pasic
2022-02-07 19:39 ` Tony Krowiak
2022-02-08 1:38 ` Halil Pasic
2022-02-08 3:27 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 15/15] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
2021-10-27 14:24 ` [PATCH v17 00/15] s390/vfio-ap: dynamic configuration support Tony Krowiak
2021-11-02 19:23 ` Tony Krowiak
2021-11-15 15:45 ` Tony Krowiak
2021-11-22 16:12 ` Tony Krowiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211021152332.70455-9-akrowiak@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=fiuczy@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).