[..]
diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index ff2b05d2aef1..25636e6bf893 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -9,6 +9,7 @@
#include <linux/mod_devicetable.h>
#include <linux/slab.h>
#include <linux/string.h>
+#include <asm/zcrypt.h>
#include "vfio_ap_private.h"
#define VFIO_AP_ROOT_NAME "vfio_ap"
@@ -33,7 +34,7 @@ struct ap_matrix_dev matrix_dev = {
.misc_dev = {
MISC_DYNAMIC_MINOR,
VFIO_AP_DEV_NAME,
- }
+ },
Should go into previous patch?
Should not have happened at all. Is a result of the abandoned
idea to initialize the mutex and the list with the initializer
list.
};
/* Only type 10 adapters (CEX4 and later) are supported
@@ -65,6 +66,21 @@ static int vfio_ap_matrix_dev_create(void)
{
int ret;
+ mutex_init(&matrix_dev.lock);
+ INIT_LIST_HEAD(&matrix_dev.mdev_list);
+
+ /* Test if PQAP(QCI) instruction is available */
+ if (test_facility(12)) {
+ ret = ap_qci(&matrix_dev.info);
+ if (ret && (ret != -EOPNOTSUPP)) {
So, is facility 12 a pre-req for PQAP(QCI)? Can the code work if
matrix_dev.info is not populated?
Yes and yes. It's basically only used in vfio_ap_matrix_init() and it
has fallbacks.
+#define VFOP_AP_MDEV_TYPE_HWVIRT "passthrough"
typo ^^^^
Nod.
+#define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
(...)
diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index 02c878cbd011..c2fd4a3e0ae3 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -10,6 +10,10 @@
#include <linux/types.h>
#include <linux/miscdevice.h>
+#include <linux/device.h>
+#include <linux/mdev.h>
+#include <linux/delay.h>
+#include <linux/mutex.h>
#include "ap_bus.h"
@@ -18,13 +22,55 @@
struct ap_matrix_dev {
struct miscdevice misc_dev;
+ atomic_t available_instances;
+ struct ap_config_info info;
+ struct list_head mdev_list;
+ struct mutex lock;
};
+/**
+ * Lockin strategy: take the matix_dev.lock mutex each time we fiddle
s/Lockin/Locking/
+ * with state managed by the vfio_ap driver (be it using the
+ * mdev_list or be it readin or writing the state of a single
s/readin/reading/
+ * ap_matrix_mdev device). It's quite coarse but we don't expect
+ * much contention.
+ */
extern struct ap_matrix_dev matrix_dev;
+/**
+ * The AP matrix is comprised of three bit masks identifying the adapters,
+ * queues (domains) and control domains that belong to an AP matrix. The bits i
s/i/in/
all nod
[..]
