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 v18 09/18] s390/vfio-ap: introduce new mutex to control access to the KVM pointer
Date: Mon, 14 Feb 2022 19:50:31 -0500 [thread overview]
Message-ID: <20220215005040.52697-10-akrowiak@linux.ibm.com> (raw)
In-Reply-To: <20220215005040.52697-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. 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 0cc00c8d4050 ("Fix circular lockdep when setting/clearing
crypto masks")
* see commit 86956e70761b ("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:
1. 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.
2. To add matrix_mdev instances to or remove them from
matrix_dev->mdev_list. This is necessary to ensure the proper locking
order when the list is iterated to find an ap_matrix_mdev instance for
the purpose of plugging/unplugging AP devices passed through to a KVM
guest; for example, when a queue device is bound to (probe callback) or
removed from (remove callback) the vfio_ap device driver.
For example, when a queue device is removed from the vfio_ap device
driver, if the adapter is passed through to a KVM guest, it will have to
be unplugged. Since the vfio_ap device driver only knows the APQN of the
queue device when it is removed, in order to figure out whether the
adapter is passed through, the matrix_mdev object to which the queue is
assigned will have to be found. Its KVM pointer (matrix_mdev->kvm) can
then be used to determine if the mediated device is passed through
(matrix_mdev->kvm != NULL) and if so, to unplug the adapter.
In addition to introducing the matrix_mdev->guests_lock mutex, the
matrix_dev->lock mutex is being renamed to matrix_dev->mdevs_lock to
better reflect its purpose, which is to control access to the state of the
mediated devices under the control of the vfio_ap device driver.
It is not necessary to take the matrix_dev->guests_lock to access the KVM
pointer if the pointer is not used to plug/unplug AP devices; however, in
this case, the matrix_dev->mdevs_lock must be held in order to access the
KVM pointer since it set and cleared under the protection of the
mdevs_lock.
A case in point is the function that handles interception of the PQAP(AQIC)
instruction sub-function by the host. This handler needs to access the KVM
pointer, but only for the purposes of setting or clearing IRQ resources, so
only the matrix_dev->mdevs_lock needs to be held.
The proper locking order must be maintained whenever plugging/unplugging
AP devices passed through to a KVM guest under the control of the vfio_ap
device driver:
matrix_dev->guests_lock
matrix_mdev->kvm->lock
matrix_dev->mdevs_lock
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
---
drivers/s390/crypto/vfio_ap_drv.c | 7 ++-
drivers/s390/crypto/vfio_ap_ops.c | 81 +++++++++++++++------------
drivers/s390/crypto/vfio_ap_private.h | 17 ++++--
3 files changed, 61 insertions(+), 44 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index 5013a5531171..e8f3540ebfda 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -68,7 +68,7 @@ static ssize_t status_show(struct device *dev,
struct ap_matrix_mdev *matrix_mdev;
struct ap_device *apdev = to_ap_dev(dev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->guests_lock);
q = dev_get_drvdata(&apdev->device);
matrix_mdev = vfio_ap_mdev_for_queue(q);
@@ -84,7 +84,7 @@ static ssize_t status_show(struct device *dev,
AP_QUEUE_UNASSIGNED);
}
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->guests_lock);
return nchars;
}
@@ -155,8 +155,9 @@ static int vfio_ap_matrix_dev_create(void)
goto matrix_alloc_err;
}
- mutex_init(&matrix_dev->lock);
+ 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_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index f2b98f347f9f..623a4b38676d 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -278,7 +278,7 @@ static int handle_pqap(struct kvm_vcpu *vcpu)
return -EOPNOTSUPP;
apqn = vcpu->run->s.regs.gprs[0] & 0xffff;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
if (!vcpu->kvm->arch.crypto.pqap_hook)
goto out_unlock;
@@ -305,7 +305,7 @@ static int handle_pqap(struct kvm_vcpu *vcpu)
out_unlock:
memcpy(&vcpu->run->s.regs.gprs[1], &qstatus, sizeof(qstatus));
vcpu->run->s.regs.gprs[1] >>= 32;
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return 0;
}
@@ -396,9 +396,9 @@ static int vfio_ap_mdev_probe(struct mdev_device *mdev)
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
hash_init(matrix_mdev->qtable.queues);
mdev_set_drvdata(mdev, matrix_mdev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->guests_lock);
list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->guests_lock);
ret = vfio_register_emulated_iommu_dev(&matrix_mdev->vdev);
if (ret)
@@ -407,9 +407,9 @@ static int vfio_ap_mdev_probe(struct mdev_device *mdev)
return 0;
err_list:
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->guests_lock);
list_del(&matrix_mdev->node);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->guests_lock);
vfio_uninit_group_dev(&matrix_mdev->vdev);
kfree(matrix_mdev);
err_dec_available:
@@ -472,11 +472,11 @@ static void vfio_ap_mdev_remove(struct mdev_device *mdev)
vfio_unregister_group_dev(&matrix_mdev->vdev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
vfio_ap_mdev_reset_queues(matrix_mdev);
vfio_ap_mdev_unlink_fr_queues(matrix_mdev);
list_del(&matrix_mdev->node);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
vfio_uninit_group_dev(&matrix_mdev->vdev);
kfree(matrix_mdev);
atomic_inc(&matrix_dev->available_instances);
@@ -652,7 +652,8 @@ static ssize_t assign_adapter_store(struct device *dev,
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->guests_lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
/* If the KVM guest is running, disallow assignment of adapter */
if (matrix_mdev->kvm) {
@@ -683,7 +684,8 @@ static ssize_t assign_adapter_store(struct device *dev,
vfio_ap_mdev_filter_matrix(apm, matrix_mdev->matrix.aqm, matrix_mdev);
ret = count;
done:
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
+ mutex_unlock(&matrix_dev->guests_lock);
return ret;
}
@@ -726,7 +728,7 @@ static ssize_t unassign_adapter_store(struct device *dev,
unsigned long apid;
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
/* If the KVM guest is running, disallow unassignment of adapter */
if (matrix_mdev->kvm) {
@@ -751,7 +753,7 @@ static ssize_t unassign_adapter_store(struct device *dev,
ret = count;
done:
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return ret;
}
static DEVICE_ATTR_WO(unassign_adapter);
@@ -806,7 +808,8 @@ static ssize_t assign_domain_store(struct device *dev,
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
unsigned long max_apqi = matrix_mdev->matrix.aqm_max;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->guests_lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
/* If the KVM guest is running, disallow assignment of domain */
if (matrix_mdev->kvm) {
@@ -836,7 +839,8 @@ static ssize_t assign_domain_store(struct device *dev,
vfio_ap_mdev_filter_matrix(matrix_mdev->matrix.apm, aqm, matrix_mdev);
ret = count;
done:
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
+ mutex_unlock(&matrix_dev->guests_lock);
return ret;
}
@@ -879,7 +883,7 @@ static ssize_t unassign_domain_store(struct device *dev,
unsigned long apqi;
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
/* If the KVM guest is running, disallow unassignment of domain */
if (matrix_mdev->kvm) {
@@ -905,7 +909,7 @@ static ssize_t unassign_domain_store(struct device *dev,
ret = count;
done:
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return ret;
}
static DEVICE_ATTR_WO(unassign_domain);
@@ -932,7 +936,7 @@ static ssize_t assign_control_domain_store(struct device *dev,
unsigned long id;
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
/* If the KVM guest is running, disallow assignment of control domain */
if (matrix_mdev->kvm) {
@@ -958,7 +962,7 @@ static ssize_t assign_control_domain_store(struct device *dev,
vfio_ap_mdev_filter_cdoms(matrix_mdev);
ret = count;
done:
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return ret;
}
static DEVICE_ATTR_WO(assign_control_domain);
@@ -986,7 +990,7 @@ static ssize_t unassign_control_domain_store(struct device *dev,
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
unsigned long max_domid = matrix_mdev->matrix.adm_max;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
/* If a KVM guest is running, disallow unassignment of control domain */
if (matrix_mdev->kvm) {
@@ -1009,7 +1013,7 @@ static ssize_t unassign_control_domain_store(struct device *dev,
ret = count;
done:
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return ret;
}
static DEVICE_ATTR_WO(unassign_control_domain);
@@ -1025,13 +1029,13 @@ static ssize_t control_domains_show(struct device *dev,
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(dev);
unsigned long max_domid = matrix_mdev->matrix.adm_max;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
for_each_set_bit_inv(id, matrix_mdev->matrix.adm, max_domid + 1) {
n = sprintf(bufpos, "%04lx\n", id);
bufpos += n;
nchars += n;
}
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return nchars;
}
@@ -1054,7 +1058,7 @@ static ssize_t matrix_show(struct device *dev, struct device_attribute *attr,
apid1 = find_first_bit_inv(matrix_mdev->matrix.apm, napm_bits);
apqi1 = find_first_bit_inv(matrix_mdev->matrix.aqm, naqm_bits);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
if ((apid1 < napm_bits) && (apqi1 < naqm_bits)) {
for_each_set_bit_inv(apid, matrix_mdev->matrix.apm, napm_bits) {
@@ -1080,7 +1084,7 @@ static ssize_t matrix_show(struct device *dev, struct device_attribute *attr,
}
}
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return nchars;
}
@@ -1134,13 +1138,15 @@ static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,
kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook;
up_write(&kvm->arch.crypto.pqap_hook_rwsem);
+ mutex_lock(&matrix_dev->guests_lock);
mutex_lock(&kvm->lock);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
list_for_each_entry(m, &matrix_dev->mdev_list, node) {
if (m != matrix_mdev && m->kvm == kvm) {
+ mutex_unlock(&matrix_dev->mdevs_lock);
mutex_unlock(&kvm->lock);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->guests_lock);
return -EPERM;
}
}
@@ -1151,8 +1157,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(&matrix_dev->mdevs_lock);
mutex_unlock(&kvm->lock);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->guests_lock);
}
return 0;
@@ -1210,16 +1217,18 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev,
kvm->arch.crypto.pqap_hook = NULL;
up_write(&kvm->arch.crypto.pqap_hook_rwsem);
+ mutex_lock(&matrix_dev->guests_lock);
mutex_lock(&kvm->lock);
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
kvm_arch_crypto_clear_masks(kvm);
vfio_ap_mdev_reset_queues(matrix_mdev);
kvm_put_kvm(kvm);
matrix_mdev->kvm = NULL;
+ mutex_unlock(&matrix_dev->mdevs_lock);
mutex_unlock(&kvm->lock);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->guests_lock);
}
}
@@ -1396,7 +1405,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct vfio_device *vdev,
container_of(vdev, struct ap_matrix_mdev, vdev);
int ret;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
switch (cmd) {
case VFIO_DEVICE_GET_INFO:
ret = vfio_ap_mdev_get_device_info(arg);
@@ -1408,7 +1417,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct vfio_device *vdev,
ret = -EOPNOTSUPP;
break;
}
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
return ret;
}
@@ -1493,7 +1502,8 @@ int vfio_ap_mdev_probe_queue(struct ap_device *apdev)
if (!q)
return -ENOMEM;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->guests_lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
q->apqn = to_ap_queue(&apdev->device)->qid;
q->saved_isc = VFIO_AP_ISC_INVALID;
vfio_ap_queue_link_mdev(q);
@@ -1504,7 +1514,8 @@ int vfio_ap_mdev_probe_queue(struct ap_device *apdev)
q->matrix_mdev);
}
dev_set_drvdata(&apdev->device, q);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
+ mutex_unlock(&matrix_dev->guests_lock);
return 0;
}
@@ -1514,7 +1525,7 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
unsigned long apid;
struct vfio_ap_queue *q;
- mutex_lock(&matrix_dev->lock);
+ mutex_lock(&matrix_dev->mdevs_lock);
q = dev_get_drvdata(&apdev->device);
if (q->matrix_mdev) {
@@ -1528,5 +1539,5 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
vfio_ap_mdev_reset_queue(q, 1);
dev_set_drvdata(&apdev->device, NULL);
kfree(q);
- mutex_unlock(&matrix_dev->lock);
+ mutex_unlock(&matrix_dev->mdevs_lock);
}
diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index fa11a7e91e24..7e82a72d2083 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -33,20 +33,25 @@
* @available_instances: number of mediated matrix devices that can be created
* @info: the struct containing the output from the PQAP(QCI) instruction
* @mdev_list: the list of mediated matrix devices created
- * @lock: mutex for locking the AP matrix device. This lock will be
- * taken every time we fiddle with state managed by the vfio_ap
- * driver, be it using @mdev_list or writing the state of a
- * single ap_matrix_mdev device. It's quite coarse but we don't
- * expect much contention.
+ * @mdevs_lock: mutex for locking the ap_matrix_mdev devices under the control
+ * of the vfio_ap device driver. This lock will be taken every time
+ * we fiddle with state of an 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;
atomic_t available_instances;
struct ap_config_info info;
struct list_head mdev_list;
- struct mutex lock;
+ struct mutex mdevs_lock;
struct ap_driver *vfio_ap_drv;
+ struct mutex guests_lock;
};
extern struct ap_matrix_dev *matrix_dev;
--
2.31.1
next prev parent reply other threads:[~2022-02-15 0:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-15 0:50 [PATCH v18 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 01/18] s390/ap: driver callback to indicate resource in use Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 02/18] s390/ap: notify drivers on config changed and scan complete callbacks Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 03/18] s390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 04/18] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 05/18] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 06/18] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 07/18] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev Tony Krowiak
2022-03-02 19:35 ` Jason J. Herne
2022-03-02 23:43 ` Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 08/18] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2022-03-03 15:39 ` Jason J. Herne
2022-03-07 12:31 ` Tony Krowiak
2022-03-07 13:27 ` Halil Pasic
2022-03-07 14:10 ` Tony Krowiak
2022-03-07 17:10 ` Halil Pasic
2022-03-07 23:45 ` Tony Krowiak
2022-03-08 10:06 ` Halil Pasic
2022-03-08 15:36 ` Tony Krowiak
2022-03-08 15:39 ` Jason J. Herne
2022-03-09 0:56 ` Halil Pasic
2022-02-15 0:50 ` Tony Krowiak [this message]
2022-02-15 0:50 ` [PATCH v18 10/18] s390/vfio-ap: allow hot plug/unplug of AP devices when assigned/unassigned Tony Krowiak
2022-03-11 14:26 ` Jason J. Herne
2022-03-11 16:07 ` Tony Krowiak
2022-03-14 13:17 ` Jason J. Herne
2022-03-18 17:30 ` Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 11/18] s390/vfio-ap: hot plug/unplug of AP devices when probed/removed Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 12/18] s390/vfio-ap: reset queues after adapter/domain unassignment Tony Krowiak
2022-03-15 14:13 ` Jason J. Herne
2022-03-18 17:54 ` Tony Krowiak
2022-03-18 22:13 ` Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 13/18] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2022-03-22 13:13 ` Jason J. Herne
2022-03-22 13:30 ` Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 14/18] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2022-03-22 13:22 ` Jason J. Herne
2022-03-22 13:41 ` Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 15/18] s390/vfio-ap: handle config changed and scan complete notification Tony Krowiak
2022-03-24 14:09 ` Jason J. Herne
2022-03-30 19:26 ` Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 16/18] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
2022-02-15 0:50 ` [PATCH v18 17/18] s390/Docs: new doc describing lock usage by the vfio_ap device driver Tony Krowiak
2022-03-31 0:28 ` Halil Pasic
2022-04-04 21:34 ` Tony Krowiak
2022-04-06 8:23 ` Halil Pasic
2022-02-15 0:50 ` [PATCH v18 18/18] MAINTAINERS: pick up all vfio_ap docs for VFIO AP maintainers Tony Krowiak
2022-02-22 19:09 ` [PATCH v18 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2022-02-28 15:53 ` Tony Krowiak
2022-03-02 14:10 ` Jason J. Herne
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=20220215005040.52697-10-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