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,
agordeev@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com
Subject: [PATCH v9 00/15] s390/vfio-ap: Add live guest migration support
Date: Tue, 13 Oct 2026 11:32:04 -0400 [thread overview]
Message-ID: <20261013153219.3534306-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 control
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 v8 => v9:
~~~~~~~~~~~~~~~~~~~
Patch 07/15: File ops called to save the vfio device migration state
* vfio_ap_stop_copy_read()
~ Advance *pos only after copy_to_user() succeeds
~ Removed the read_pos snapshot; it is not needed because mdevs_lock
is held from reading *pos through copy_to_user()
~ Removed the incorrect statement that ap_config is freed when the
migration fd is released
Patch 10/15: Add method to set a new guest AP configuration
* vfio_ap_matrix_init()()
~ Removed duplicate prototype from vfio_ap_private.h
Patch 11/15: File ops called to resume the vfio device migration
* vfio_ap_resuming_init()
~ Now pre-allocates a worst-case receive buffer (VFIO_AP_CONFIG_MAX_SIZE)
with kvzalloc()
* vfio_ap_resuming_write()
~ Removed the multi-phase allocation of
matrix_mdev->mig_data->resuming_mig_file.ap_config
o Removed staging buffer and uses pre-allocated receive buffer
(matrix_mdev->mig_data->resuming_mig_file.ap_config)
o Data is accumulated in ap_config at filp->f_pos; the new guest
configuration is processed once all expected bytes are received
~ Now holds ap_attr_mutex and the mdev update locks for
the whole write instead of dropping mdevs_lock between the copy and
the configuration update
~ No longer calls copy_from_user() with locks held; a buffer that blocks
indefinitely could stall all AP attribute updates and mdev operations
on the host as well as the guest's kvm->lock
o vmemdup_user() copies the user data into a kernel buffer before
any lock is taken
o memcpy() into ap_config is under the locks
o Kernel buffer is freed with kvfree() after locks are released
* validate_resuming_write_parms()
~ Dropped the loff_t *pos parameter
~ Dropped the staging buffer/ap_config consistency check; the only bounds
check is f_pos + len <= VFIO_AP_CONFIG_MAX_SIZE
* do_post_copy_processing()
~ Removed the mig_data NULL re-check since the function no longer
takes any locks
Anthony Krowiak (15):
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: Prepare lock helpers and matrix init for cross-file use
s390/vfio-ap: Add method to set a new guest AP configuration
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: Add 'migratable' feature to sysfs 'features' attribute
s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst
Documentation/arch/s390/vfio-ap.rst | 616 ++++++++--
drivers/s390/crypto/Makefile | 2 +-
drivers/s390/crypto/vfio_ap_drv.c | 14 +-
drivers/s390/crypto/vfio_ap_migration.c | 1504 +++++++++++++++++++++++
drivers/s390/crypto/vfio_ap_ops.c | 289 +++--
drivers/s390/crypto/vfio_ap_private.h | 73 ++
6 files changed, 2297 insertions(+), 201 deletions(-)
create mode 100644 drivers/s390/crypto/vfio_ap_migration.c
--
2.53.0
next reply other threads:[~2026-10-13 15:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 15:32 Anthony Krowiak [this message]
2026-10-13 15:32 ` [PATCH v9 01/15] s390/vfio-ap: Provide function to get the number of queues assigned to mdev Anthony Krowiak
2026-10-13 15:38 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 02/15] s390/vfio-ap: Data structures for facilitating vfio device migration Anthony Krowiak
2026-10-13 15:40 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 03/15] s390/vfio-ap: Functions to initialize/release vfio device migration data Anthony Krowiak
2026-10-13 15:47 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 04/15] s390/vfio-ap: Reset migration state in VFIO_DEVICE_RESET ioctl handler Anthony Krowiak
2026-10-13 15:50 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 05/15] s390/vfio-ap: Callback to get/set vfio device mig state during guest migration Anthony Krowiak
2026-10-13 15:48 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 06/15] s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY Anthony Krowiak
2026-10-13 15:55 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 07/15] s390/vfio-ap: File ops called to save the vfio device migration state Anthony Krowiak
2026-10-13 15:59 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 08/15] s390/vfio-ap: Transition device migration state from STOP to RESUMING Anthony Krowiak
2026-10-13 16:00 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 09/15] s390/vfio-ap: Prepare lock helpers and matrix init for cross-file use Anthony Krowiak
2026-10-13 16:00 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 10/15] s390/vfio-ap: Add method to set a new guest AP configuration Anthony Krowiak
2026-10-13 16:03 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 11/15] s390/vfio-ap: File ops called to resume the vfio device migration Anthony Krowiak
2026-10-13 16:14 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 12/15] s390/vfio-ap: Transition device migration state to from/to STOP Anthony Krowiak
2026-10-13 16:08 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 13/15] s390/vfio-ap: Callback to get the size of data to be migrated during guest migration Anthony Krowiak
2026-10-13 16:10 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 14/15] s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute Anthony Krowiak
2026-10-13 16:12 ` sashiko-bot
2026-10-13 15:32 ` [PATCH v9 15/15] s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst Anthony Krowiak
2026-10-13 16:10 ` sashiko-bot
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=20261013153219.3534306-1-akrowiak@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=alex@shazbot.org \
--cc=borntraeger@de.ibm.com \
--cc=fiuczy@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.