Re: [PATCH v6 09/21] s390: vfio-ap: structure for storing mdev matrix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/06/2018 04:26 PM, Halil Pasic wrote:


On 06/29/2018 11:11 PM, Tony Krowiak wrote:
From: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>

Introduces a new structure for storing the AP matrix configured
for the mediated matrix device via its sysfs attributes files.

Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
---
  drivers/s390/crypto/vfio_ap_ops.c     |   12 ++++++++++++
  drivers/s390/crypto/vfio_ap_private.h |   24 ++++++++++++++++++++++++
  2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 4e61e33..bf7ed9f 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -20,6 +20,17 @@
  DEFINE_SPINLOCK(mdev_list_lock);
  LIST_HEAD(mdev_list);

+static void vfio_ap_matrix_init(struct ap_matrix *matrix)
+{
+    /* Test if PQAP(QCI) instruction is available */
+    if (test_facility(12))
+        ap_qci(&matrix->info);
+
+    matrix->apm_max = matrix->info.apxa ? matrix->info.Na : 63;
+    matrix->aqm_max = matrix->info.apxa ? matrix->info.Nd : 15;
+    matrix->adm_max = matrix->info.apxa ? matrix->info.Nd : 15;
+}
+
static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
  {
      struct ap_matrix_dev *matrix_dev =
@@ -31,6 +42,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
          return -ENOMEM;

      matrix_mdev->name = dev_name(mdev_dev(mdev));
+    vfio_ap_matrix_init(&matrix_mdev->matrix);
      mdev_set_drvdata(mdev, matrix_mdev);

if (atomic_dec_if_positive(&matrix_dev->available_instances) < 0) { diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index 3de1275..ae771f5 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -29,9 +29,33 @@ struct ap_matrix_dev {
      atomic_t available_instances;
  };

+/**
+ * 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 + * each mask, from least significant to most significant bit, correspond to IDs + * 0 to 255. When a bit is set, the corresponding ID belongs to the matrix.
+ *
+ * @apm identifies the AP adapters in the matrix
+ * @apm_max: max adapter number in @apm
+ * @aqm identifies the AP queues (domains) in the matrix
+ * @aqm_max: max domain number in @aqm
+ * @adm identifies the AP control domains in the matrix
+ * @adm_max: max domain number in @adm
+ */
+struct ap_matrix {
+    unsigned long apm_max;
+    DECLARE_BITMAP(apm, 256);
+    unsigned long aqm_max;
+    DECLARE_BITMAP(aqm, 256);
+    unsigned long adm_max;
+    DECLARE_BITMAP(adm, 256);
+    struct ap_config_info info;

Why do we maintain (and populate by doing a QCI) the info member on a
per mdev device basis?

That is a mistake, I am going to move it to struct ap_matrix_dev and
execute the QCI instruction when the matrix device is registered
with mdev during driver initialization.



+};
+
  struct ap_matrix_mdev {
      const char *name;
      struct list_head list;
+    struct ap_matrix matrix;
  };

  static struct ap_matrix_dev *to_ap_matrix_dev(struct device *dev)






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux