From: Anthony 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, borntraeger@de.ibm.com,
mjrosato@linux.ibm.com, pasic@linux.ibm.com, alex@shazbot.org,
kwankhede@nvidia.com, fiuczy@linux.ibm.com, pbonzini@redhat.com,
frankja@linux.ibm.com, imbrenda@linux.ibm.com
Subject: [PATCH v1 22/24] s390/vfio-ap: Provide API to query whether migration is in progress
Date: Wed, 25 Mar 2026 17:01:09 -0400 [thread overview]
Message-ID: <20260325210149.888028-23-akrowiak@linux.ibm.com> (raw)
In-Reply-To: <20260325210149.888028-1-akrowiak@linux.ibm.com>
Provides an AP to query whether a live guest migration is in progress. This
can be called to determine whether an action should be allowed during
migration; for example, allowing a system administrator to disable
migration while it is in progress. Other uses may be to prevent changing
a guest's AP configuration while a migration is in progress.
The only means the vfio_ap device driver has to determine that a migration
is in progress is via the callback functions specified in the
'struct vfio_migration_ops' object associated with the vfio device.
The very first callback invoked during migration is the callback specified
in the 'migration_get_data_size' field of the structure. This callback will
set a flag indicating that migration is in progress. The flag will be
cleared when the vfio device migration state transitions from
VFIO_DEVICE_STATE_STOP_COPY to VFIO_DEVICE_STATE_STOP. At this point, the
internal state of the vfio device on the source has been copied and will
be restored on the target.
Note that the 'migration_get_data_size' callback occurs after migration has
been initiated, so there is a short period of time during which the API
will erroneously indicate migration is not in progress. This,
unfortunately, is unavoidable given the only means of determining that a
migration is in progress is via these callbacks.
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
drivers/s390/crypto/vfio_ap_migration.c | 40 ++++++++++++++++++++++++-
drivers/s390/crypto/vfio_ap_private.h | 1 +
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/vfio_ap_migration.c b/drivers/s390/crypto/vfio_ap_migration.c
index fa163b129c66..8a7628fcf285 100644
--- a/drivers/s390/crypto/vfio_ap_migration.c
+++ b/drivers/s390/crypto/vfio_ap_migration.c
@@ -47,11 +47,14 @@
* @mig_state: the current migration state
* @resuming_migf: the object used to resume the target guest
* @saving_migf: the object used to save the state of the source guest
+ * @mig_in_progress flag indicating whether migration is in progress (true)
+ * or not (false)
*/
struct vfio_ap_migration_data {
enum vfio_device_mig_state mig_state;
struct vfio_ap_migration_file *resuming_migf;
struct vfio_ap_migration_file *saving_migf;
+ bool mig_in_progress;
};
/**
@@ -971,18 +974,30 @@ vfio_ap_transition_to_state(struct ap_matrix_mdev *matrix_mdev,
return ERR_PTR(-EINVAL);
}
+static void vfio_ap_set_mig_in_progress(struct vfio_ap_migration_data *mig_data,
+ enum vfio_device_mig_state prev_state,
+ enum vfio_device_mig_state new_state)
+{
+ lockdep_assert_held(&matrix_dev->mdevs_lock);
+ if (prev_state == VFIO_DEVICE_STATE_STOP_COPY &&
+ new_state == VFIO_DEVICE_STATE_STOP) {
+ mig_data->mig_in_progress = false;
+ }
+}
+
static struct file *vfio_ap_set_state(struct vfio_device *vdev,
enum vfio_device_mig_state new_state)
{
int ret;
struct file *filp = NULL;
struct ap_matrix_mdev *matrix_mdev;
- enum vfio_device_mig_state next_state;
+ enum vfio_device_mig_state prev_state, next_state;
struct vfio_ap_migration_data *mig_data;
mutex_lock(&matrix_dev->mdevs_lock);
matrix_mdev = container_of(vdev, struct ap_matrix_mdev, vdev);
mig_data = matrix_mdev->mig_data;
+ prev_state = mig_data->mig_state;
dev_dbg(vdev->dev, "%s -> %d\n", __func__, new_state);
while (mig_data->mig_state != new_state) {
@@ -1006,6 +1021,7 @@ static struct file *vfio_ap_set_state(struct vfio_device *vdev,
}
}
+ vfio_ap_set_mig_in_progress(mig_data, prev_state, new_state);
mutex_unlock(&matrix_dev->mdevs_lock);
return filp;
@@ -1031,12 +1047,15 @@ static int vfio_ap_get_state(struct vfio_device *vdev,
static int vfio_ap_get_data_size(struct vfio_device *vdev,
unsigned long *stop_copy_length)
{
+ struct vfio_ap_migration_data *mig_data;
struct ap_matrix_mdev *matrix_mdev;
size_t qinfo_sz;
int num_queues;
mutex_lock(&matrix_dev->mdevs_lock);
matrix_mdev = container_of(vdev, struct ap_matrix_mdev, vdev);
+ mig_data = matrix_mdev->mig_data;
+ mig_data->mig_in_progress = true;
num_queues = vfio_ap_mdev_get_num_queues(&matrix_mdev->shadow_apcb);
qinfo_sz = num_queues * sizeof(struct vfio_ap_queue_info);
*stop_copy_length = qinfo_sz + sizeof(struct vfio_ap_config);
@@ -1051,6 +1070,24 @@ static const struct vfio_migration_ops vfio_ap_migration_ops = {
.migration_get_data_size = vfio_ap_get_data_size,
};
+/**
+ * vfio_ap_migration_in_progress: Indicates whether a live guest migration is in
+ * progress or not.
+ *
+ * @matrix_mdev: pointer to object maintaining the vfio device state
+ *
+ * Return: returns true if a migration is in progress; otherwise, returns false.
+ */
+bool vfio_ap_migration_in_progress(struct ap_matrix_mdev *matrix_mdev)
+{
+ struct vfio_ap_migration_data *mig_data;
+
+ lockdep_assert_held(&matrix_dev->mdevs_lock);
+ mig_data = matrix_mdev->mig_data;
+
+ return mig_data->mig_in_progress;
+}
+
/**
* vfio_ap_init_migration_data - initialize migration data and functions
*
@@ -1069,6 +1106,7 @@ int vfio_ap_init_migration_data(struct ap_matrix_mdev *matrix_mdev)
return -ENOMEM;
mig_data->mig_state = VFIO_DEVICE_STATE_STOP;
+ mig_data->mig_in_progress = false;
matrix_mdev->vdev.migration_flags = VFIO_MIGRATION_STOP_COPY;
matrix_mdev->vdev.mig_ops = &vfio_ap_migration_ops;
matrix_mdev->mig_data = mig_data;
diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index cad49b509f7a..e04644c335fe 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -183,5 +183,6 @@ void vfio_ap_on_scan_complete(struct ap_config_info *new_config_info,
int vfio_ap_init_migration_data(struct ap_matrix_mdev *matrix_mdev);
void vfio_ap_release_migration_data(struct ap_matrix_mdev *matrix_mdev);
+bool vfio_ap_migration_in_progress(struct ap_matrix_mdev *matrix_mdev);
#endif /* _VFIO_AP_PRIVATE_H_ */
--
2.52.0
next prev parent reply other threads:[~2026-03-25 21:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 21:00 [PATCH v1 00/23] s390/vfio-ap: Implement live guest migration of guests using AP devices Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 01/24] fixup! KVM: s390: Remove non-atomic dat_crstep_xchg() Anthony Krowiak
2026-03-25 21:30 ` Matthew Rosato
2026-03-26 10:19 ` Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 02/24] s390/vfio-ap: Store queue hardware info when probed Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 03/24] s390/vfio-ap: Provide access to queue objects and related info Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 04/24] s390/vfio-ap: Add header file for xfer of vfio device caps to userspace Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 05/24] MAINTAINERS: Add new header file for the S390 VFIO AP DRIVER maintainers Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 06/24] s390/vfio-ap: A sysfs 'migratable' attribute to enable/disable migration of guest Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 07/24] s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 08/24] s390/vfio-ap: Signal event to enable/disable live guest migration Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 09/24] s390/vfio-ap: Return value of sysfs migratable attribute from VFIO_DEVICE_GET_INFO ioctl Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 10/24] s390/vfio-ap: Data structures for facilitating vfio device migration Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 11/24] s390/vfio-ap: Initialize/release vfio device migration data Anthony Krowiak
2026-03-25 21:00 ` [PATCH v1 12/24] s390-vfio-ap: Callback to set vfio device mig state during guest migration Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 13/24] s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 14/24] s390/vfio-ap: File ops called to save the vfio device migration state Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 15/24] s390/vfio-ap: Transition device migration state from STOP to RESUMING Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 16/24] s390/vfio-ap: File ops called to resume the vfio device migration Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 17/24] s390/vfio-ap: Transition device migration state from RESUMING to STOP Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 18/24] s390/vfio-ap: Transition device migration state from STOP_COPY " Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 19/24] s390/vfio-ap: Transition device migration state from STOP to RUNNING and vice versa Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 20/24] s390-vfio-ap: Callback to get the current vfio device migration state Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 21/24] s390/vfio-ap: Callback to get the size of data to be migrated during guest migration Anthony Krowiak
2026-03-25 21:01 ` Anthony Krowiak [this message]
2026-03-25 21:01 ` [PATCH v1 23/24] s390/vfio-ap: Disallow blocking migration in progress Anthony Krowiak
2026-03-25 21:01 ` [PATCH v1 24/24] s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst Anthony Krowiak
2026-03-30 16:27 ` [PATCH v1 00/23] s390/vfio-ap: Implement live guest migration of guests using AP devices Alex Williamson
2026-03-31 11:17 ` Anthony Krowiak
2026-03-31 12:07 ` Anthony Krowiak
2026-03-31 17:40 ` Alex Williamson
2026-04-01 13:38 ` Anthony Krowiak
2026-04-01 16:57 ` Alex Williamson
2026-04-02 12:03 ` Anthony Krowiak
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=20260325210149.888028-23-akrowiak@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex@shazbot.org \
--cc=borntraeger@de.ibm.com \
--cc=fiuczy@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@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 \
--cc=pbonzini@redhat.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