[v4,3/6] s390/vfio-ap: let 'on_scan_complete' callback filter matrix and update guest's APCB

Message ID 20240115185441.31526-4-akrowiak@linux.ibm.com
State New
Headers
Series s390/vfio-ap: reset queues removed from guest's AP configuration |

Commit Message

Anthony Krowiak Jan. 15, 2024, 6:54 p.m. UTC
  From: Tony Krowiak <akrowiak@linux.ibm.com>

When adapters and/or domains are added to the host's AP configuration, this
may result in multiple queue devices getting created and probed by the
vfio_ap device driver. For each queue device probed, the matrix of adapters
and domains assigned to a matrix mdev will be filtered to update the
guest's APCB. If any adapters or domains get added to or removed from the
APCB, the guest's AP configuration will be dynamically updated (i.e., hot
plug/unplug). To dynamically update the guest's configuration, its VCPUs
must be taken out of SIE for the period of time it takes to make the
update. This is disruptive to the guest's operation and if there are many
queues probed due to a change in the host's AP configuration, this could be
troublesome. The problem is exacerbated by the fact that the
'on_scan_complete' callback also filters the mdev's matrix and updates
the guest's AP configuration.

In order to reduce the potential amount of disruption to the guest that may
result from a change to the host's AP configuration, let's bypass the
filtering of the matrix and updating of the guest's AP configuration in the
probe callback - if due to a host config change - and defer it until the
'on_scan_complete' callback is invoked after the AP bus finishes its device
scan operation. This way the filtering and updating will be performed only
once regardless of the number of queues added.

Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_ops.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)
  

Comments

Alexander Gordeev Jan. 16, 2024, 8:34 a.m. UTC | #1
On Mon, Jan 15, 2024 at 01:54:33PM -0500, Tony Krowiak wrote:
Hi Tony,

> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> Reviewed-by: Halil Pasic <pasic@linux.ibm.com>

No Fixes tag for this patch?

Thanks!
  
Anthony Krowiak Jan. 16, 2024, 2:57 p.m. UTC | #2
On 1/16/24 3:34 AM, Alexander Gordeev wrote:
> On Mon, Jan 15, 2024 at 01:54:33PM -0500, Tony Krowiak wrote:
> Hi Tony,
>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
> No Fixes tag for this patch?


This patch is more of an enhancement as opposed to a bug, so no Fixes.


>
> Thanks!
>
  
Alexander Gordeev Jan. 16, 2024, 3:53 p.m. UTC | #3
On Tue, Jan 16, 2024 at 09:57:25AM -0500, Tony Krowiak wrote:
> This patch is more of an enhancement as opposed to a bug, so no Fixes.

The preceding and rest of this series CCs stable@vger.kernel.org and
would not apply without this patch. So I guess backporting the whole
series would be difficult.

Whether propagating the prevous patches' Fixes/stable makes any sense?

Thanks!
  
Anthony Krowiak Jan. 16, 2024, 7:07 p.m. UTC | #4
On 1/16/24 10:53 AM, Alexander Gordeev wrote:
> On Tue, Jan 16, 2024 at 09:57:25AM -0500, Tony Krowiak wrote:
>> This patch is more of an enhancement as opposed to a bug, so no Fixes.
> The preceding and rest of this series CCs stable@vger.kernel.org and
> would not apply without this patch. So I guess backporting the whole
> series would be difficult.
>
> Whether propagating the prevous patches' Fixes/stable makes any sense?


Let's put it this way; it doesn't not make sense to make this patch 
Fixes/stable. To make life easier to apply the whole series, go ahead 
and add the Fixes/stable tags.


>
> Thanks!
  

Patch

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index e825e13847fe..e45d0bf7b126 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -2101,9 +2101,22 @@  int vfio_ap_mdev_probe_queue(struct ap_device *apdev)
 	if (matrix_mdev) {
 		vfio_ap_mdev_link_queue(matrix_mdev, q);
 
+		/*
+		 * If we're in the process of handling the adding of adapters or
+		 * domains to the host's AP configuration, then let the
+		 * vfio_ap device driver's on_scan_complete callback filter the
+		 * matrix and update the guest's AP configuration after all of
+		 * the new queue devices are probed.
+		 */
+		if (!bitmap_empty(matrix_mdev->apm_add, AP_DEVICES) ||
+		    !bitmap_empty(matrix_mdev->aqm_add, AP_DOMAINS))
+			goto done;
+
 		if (vfio_ap_mdev_filter_matrix(matrix_mdev))
 			vfio_ap_mdev_update_guest_apcb(matrix_mdev);
 	}
+
+done:
 	dev_set_drvdata(&apdev->device, q);
 	release_update_locks_for_mdev(matrix_mdev);