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, freude@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com,
mjrosato@linux.ibm.com, pasic@linux.ibm.com,
alex.williamson@redhat.com, kwankhede@nvidia.com,
fiuczy@linux.ibm.com
Subject: [PATCH v11 00/14] s390/vfio-ap: Add live guest migration support
Date: Mon, 2 Nov 2026 10:14:40 -0500 [thread overview]
Message-ID: <20261102151604.2150055-1-akrowiak@linux.ibm.com> (raw)
This patch series implements live guest migration support for KVM guests
with s390 AP (Adjunct Processor) devices passed through via the VFIO
mediated device framework.
Background
~~~~~~~~~~
The vfio-ap device driver differs from typical VFIO device drivers in that
it does not virtualize a physical device. Instead, it manages AP
configuration metadata identifying the AP adapters, domains, and controls390/vfio-ap: Add live guest migration support
domains to which a guest will be granted access. These AP resources are
configured by assigning them to a vfio-ap mediated device via its sysfs
assignment interfaces. When the fd for the VFIO device is opened by
userspace, the vfio_ap device driver sets the guest's AP configuration
from the metadata stored with the mediated device. As such, the AP devices
are not accessed directly through the vfio_ap driver, so the driver has no
internal AP device state to migrate. What it does migrate is the AP
configuration metadata of the source guest.
Implementation Approach
~~~~~~~~~~~~~~~~~~~~~~~
This series implements the VFIO migration protocol using the STOP_COPY
migration flow. The key aspects are:
1. On transition of the migration state from STOP to STOP_COPY
- The vfio_ap device driver creates a filestream for userspace to use to
read the guest's AP configuration from the mdev
2. During the STOP_COPY phase
- Userspace uses the filestream created in #1 to read the source guest's
AP configuration
- The vfio_ap device driver copies the source guest's AP configuration
information to userspace
3. On transition of the migration state from STOP to RESUMING
- The vfio_ap device driver creates a filestream for userspace to use to
write the source guest's AP configuration information so it can be
restored to the mdev on the destination host.
4. During the RESUMING phase
- Userspace uses the filestream created in #3 to send the source guest's
AP configuration information to the vfio_ap device driver on the
destination host.
- The vfio_ap device driver first verifies the source guest's AP
configuration is compatible with the destination host's.
- The driver restores AP configuration to the mdev on the destination
host which automatically hot plugs the AP resources identified
therein.
5. Documentation
- Add live guest migration chapter to vfio-ap.rst
Compatibility Validation
~~~~~~~~~~~~~~~~~~~~~~~~
The series includes comprehensive validation to ensure source and
destination AP configurations are compatible. For each queue, the following
characteristics must match:
- AP type (target must be same or newer than source)
- Installed facilities (APSC, APQKM, AP4KC, SLCF)
- Operating mode (CCA, Accelerator, XCP)
- APXA facility setting
- Classification (native vs stateless functions)
- Queue usability (binding/associated state)
When incompatibilities are detected, migration fails with detailed error
messages identifying the specific queue and characteristic that caused
the failure.
Configuration Management
~~~~~~~~~~~~~~~~~~~~~~~~
This implementation does not prevent configuration changes during
migration. Configuration stability is an orchestration-layer
responsibility, consistent with other VFIO device types. The driver's
role is to validate configurations and provide clear diagnostics when
incompatibilities are detected, enabling orchestration tools to implement
appropriate policies.
QEMU patches exploiting this series:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
https://lore.kernel.org/qemu-devel/20260409141352.997844-1-akrowiak@linux.ibm.com/
Change log v10 => v11:
~~~~~~~~~~~~~~~~~~~~~
Patch 02/14: Data structures for facilitating vfio device migration
* struct vfio_ap_migration_file
~ Added @matrix_mdev back-pointer to the owning ap_matrix_mdev so
read/write file ops can reach mdev state without storing it
directly in filp->private_data
~ Added @lock mutex to serialize concurrent read/write operations
and ensure f_pos is only advanced after a successful
copy_to_user()
Patch 03/14: Functions to initialize/release vfio device migration data
* vfio_ap_init_migration_data()
~ Initialize @matrix_mdev back-pointer and @lock for both
stop_copy_mig_file and resuming_mig_file embedded in mig_data
* vfio_ap_release_migration_data()
~ Destroy @lock for both stop_copy_mig_file and resuming_mig_file
before freeing mig_data; moved from per-session release
functions vfio_ap_release_stop_copy_file() and
vfio_ap_release_resuming_file() which are called at the end
of each migration session, not at final object lifetime
Patch 05/14: Callback to get/set vfio device mig state during guest migration
* vfio_ap_mdev_set_kvm()
~ vdev->kvm changed from struct kvm * to struct file * following
upstream KVM API change; file_to_kvm_s390() now called to get
the struct kvm *
~ kvm_get_kvm() / kvm_put_kvm() removed; file reference holds
KVM lifetime
Patch 06/14: Transition guest migration state from STOP to STOP_COPY
* vfio_ap_transition_to_state()
~ Pass &mig_data->stop_copy_mig_file to vfio_ap_open_file_stream()
instead of matrix_mdev; filp->private_data is now the
vfio_ap_migration_file pointer
* vfio_ap_open_file_stream()
~ Changed first parameter from ap_matrix_mdev * to
vfio_ap_migration_file *; uses mig_file->matrix_mdev internally
* vfio_ap_release_mig_file()
~ filp->private_data is now vfio_ap_migration_file; reach
matrix_mdev via mig_file->matrix_mdev
Patch 07/14: File ops called to save the vfio device migration state
* validate_stop_copy_read_parms()
~ Added mig_file parameter; validates filp against mig_file->filp
instead of mig_data->stop_copy_mig_file.filp
~ Added lockdep_assert_held(&mig_file->lock)
~ Removed config_sz overflow check that was masking the broken
EOF logic (see vfio_ap_stop_copy_read() fix below)
* vfio_ap_stop_copy_read()
~ filp->private_data cast to vfio_ap_migration_file *; matrix_mdev
reached via mig_file->matrix_mdev
~ Acquire mig_file->lock before mdevs_lock and hold across
copy_to_user() to serialize concurrent readers and protect f_pos
~ *pos advanced only after copy_to_user() succeeds; mutex_unlock
added on -EFAULT error path
~ if (pos) return -ESPIPE guard restored (stream_open() passes
NULL for normal read(), non-NULL only for pread())
~ pos = &filp->f_pos reassignment restored after lock acquisition
~ Restore v10 EOF signaling: clamp len to remaining bytes with
min_t() and return 0 on the subsequent empty read, rather than
the broken eof-flag approach that never signaled EOF when
QEMU's read buffer did not divide evenly into config_sz
Patch 08/14: Transition device migration state from STOP to RESUMING
* vfio_ap_resuming_init()
~ Changed parameter from ap_matrix_mdev * to
vfio_ap_migration_file *
~ Store ap_config, config_sz, and filp directly into mig_file
instead of via mig_data->resuming_mig_file indirection
* vfio_ap_transition_to_state()
~ Pass &mig_data->resuming_mig_file to vfio_ap_resuming_init()
instead of matrix_mdev; removed the now-redundant assignment
of mig_data->resuming_mig_file.filp after the call
Patch 09/14: File ops called to resume the vfio device migration
* validate_resuming_write_parms()
~ Added mig_file parameter; validates filp against
mig_file->matrix_mdev->mig_data->resuming_mig_file.filp
~ Added lockdep_assert_held(&mig_file->lock)
~ Moved NULL check on mig_data before dereference of
mig_data->resuming_mig_file.filp
* vfio_ap_resuming_write()
~ filp->private_data cast to vfio_ap_migration_file *; reach
matrix_mdev via mig_file->matrix_mdev
~ Acquire mig_file->lock before ap_attr_mutex and mdevs_lock to
serialize concurrent chunk writes on f_pos and ap_config
~ if (pos) return -ESPIPE guard restored
~ Replace get_update_locks_for_mdev() with direct mdevs_lock
acquisition; guests_lock and kvm->lock are not needed because
the pre-configured destination mdev model never modifies the
guest APCB during migration write
~ do_post_copy_validation(): replace assert_has_update_locks_for_mdev()
with lockdep_assert_held(&matrix_dev->mdevs_lock)
Patch 10/14: Transition device migration state to/from STOP
* do_post_copy_processing() wrapper collapsed directly into
do_post_copy_validation(); lockdep_assert_held() calls moved
into do_post_copy_validation()
Patch 12/14: Set up for vfio-ap device migration
* vfio_ap_setup_vfio_device_migration() kdoc
~ Removed stray "Enable" word from description
~ Collapsed double blank line between description and @matrix_mdev
Dropped patch 09/15: Prepare lock helpers and matrix init for cross-file use
* Removed: get_update_locks_for_mdev(), release_update_locks_for_mdev(),
and assert_has_update_locks_for_mdev() are no longer needed in
vfio_ap_migration.c; vfio_ap_resuming_write() now holds only
mdevs_lock directly
* Removed: vfio_ap_matrix_init() no longer needs to be public;
it was exposed so vfio_ap_resuming_write() could hot-plug the
source AP configuration into the destination guest, which the
pre-configured mdev model does not do
Anthony Krowiak (14):
s390/vfio-ap: Provide function to get the number of queues assigned to
mdev
s390/vfio-ap: Data structures for facilitating vfio device migration
s390/vfio-ap: Functions to initialize/release vfio device migration
data
s390/vfio-ap: Reset migration state in VFIO_DEVICE_RESET ioctl handler
s390/vfio-ap: Callback to get/set vfio device mig state during guest
migration
s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY
s390/vfio-ap: File ops called to save the vfio device migration state
s390/vfio-ap: Transition device migration state from STOP to RESUMING
s390/vfio-ap: File ops called to resume the vfio device migration
s390/vfio-ap: Transition device migration state to from/to STOP
s390/vfio-ap: Callback to get the size of data to be migrated during
guest migration
s390/vfio-ap: Set up for vfio-ap device migration
s390/vfio-ap: Add 'migration' feature to sysfs 'features' attribute
s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst
Documentation/arch/s390/vfio-ap.rst | 643 ++++++++--
drivers/s390/crypto/Makefile | 2 +-
drivers/s390/crypto/vfio_ap_drv.c | 14 +-
drivers/s390/crypto/vfio_ap_migration.c | 1454 +++++++++++++++++++++++
drivers/s390/crypto/vfio_ap_ops.c | 70 +-
drivers/s390/crypto/vfio_ap_private.h | 12 +
6 files changed, 2089 insertions(+), 106 deletions(-)
create mode 100644 drivers/s390/crypto/vfio_ap_migration.c
--
2.53.0
next reply other threads:[~2026-11-02 15:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 15:14 Anthony Krowiak [this message]
2026-11-02 15:14 ` [PATCH v11 01/14] s390/vfio-ap: Provide function to get the number of queues assigned to mdev Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 02/14] s390/vfio-ap: Data structures for facilitating vfio device migration Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 03/14] s390/vfio-ap: Functions to initialize/release vfio device migration data Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 04/14] s390/vfio-ap: Reset migration state in VFIO_DEVICE_RESET ioctl handler Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 05/14] s390/vfio-ap: Callback to get/set vfio device mig state during guest migration Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 06/14] s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 07/14] s390/vfio-ap: File ops called to save the vfio device migration state Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 08/14] s390/vfio-ap: Transition device migration state from STOP to RESUMING Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 09/14] s390/vfio-ap: File ops called to resume the vfio device migration Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 10/14] s390/vfio-ap: Transition device migration state to from/to STOP Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 11/14] s390/vfio-ap: Callback to get the size of data to be migrated during guest migration Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 12/14] s390/vfio-ap: Set up for vfio-ap device migration Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 13/14] s390/vfio-ap: Add 'migration' feature to sysfs 'features' attribute Anthony Krowiak
2026-11-02 15:14 ` [PATCH v11 14/14] s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst 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=20261102151604.2150055-1-akrowiak@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=fiuczy@linux.ibm.com \
--cc=freude@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 \
/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
all inboxes | Powered by JetHome®