On 3/2/22 14:35, Jason J. Herne wrote:
On 2/14/22 19:50, Tony Krowiak wrote:
Refresh the guest's APCB by filtering the APQNs assigned to the
matrix mdev
that do not reference an AP queue device bound to the vfio_ap device
driver. The mdev's APQNs will be filtered according to the following
rules:
* The APID of each adapter and the APQI of each domain that is not in
the
host's AP configuration is filtered out.
* The APID of each adapter comprising an APQN that does not reference a
queue device bound to the vfio_ap device driver is filtered. The APQNs
are derived from the Cartesian product of the APID of each adapter and
APQI of each domain assigned to the mdev.
The control domains that are not assigned to the host's AP configuration
will also be filtered before assigning them to the guest's APCB.
Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
---
drivers/s390/crypto/vfio_ap_ops.c | 96 ++++++++++++++++++++++++++++++-
1 file changed, 93 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 4b676a55f203..b67b2f0faeea 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -317,6 +317,63 @@ static void vfio_ap_matrix_init(struct
ap_config_info *info,
matrix->adm_max = info->apxa ? info->Nd : 15;
}
+static void vfio_ap_mdev_filter_cdoms(struct ap_matrix_mdev
*matrix_mdev)
+{
+ bitmap_and(matrix_mdev->shadow_apcb.adm, matrix_mdev->matrix.adm,
+ (unsigned long *)matrix_dev->info.adm, AP_DOMAINS);
+}
+
+/*
+ * vfio_ap_mdev_filter_matrix - copy the mdev's AP configuration to
the KVM
+ * guest's APCB then filter the APIDs that do not
+ * comprise at least one APQN that references a
+ * queue device bound to the vfio_ap device driver.
+ *
+ * @matrix_mdev: the mdev whose AP configuration is to be filtered.
+ */
+static void vfio_ap_mdev_filter_matrix(unsigned long *apm, unsigned
long *aqm,
+ struct ap_matrix_mdev *matrix_mdev)
+{
+ int ret;
+ unsigned long apid, apqi, apqn;
+
+ ret = ap_qci(&matrix_dev->info);
+ if (ret)
+ return;
+
+ vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
Do you need to call vfio_ap_matrix_init here? It seems to me like this
would
only be necesarry if apxa could be dynamically added or removed. Here
is a
copy of vfio_ap_matrix_init, for reference:
static void vfio_ap_matrix_init(struct ap_config_info *info,
struct ap_matrix *matrix)
{
matrix->apm_max = info->apxa ? info->Na : 63;
matrix->aqm_max = info->apxa ? info->Nd : 15;
matrix->adm_max = info->apxa ? info->Nd : 15;
}
It seems like this should be figured out once and stored when the
ap_matrix_mdev struct is first created. Unless I'm wrong, and the
status of
apxa can change dynamically, in which case the maximums would need to be
updated somewhere.
It's an interesting question to which I don't have a definitive answer.
I'll run it
by our architects. On the other hand, making this call here is not entirely
unreasonable and merely superfluous at worst, but I'll look into it.
Tony K
