mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 v8 00/15] s390/vfio-ap: Add live guest migration support
Date: Fri,  9 Oct 2026 07:42:29 -0400	[thread overview]
Message-ID: <20261009114244.1213173-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: v7 => v8:
~~~~~~~~~~~~~~~~~~~~
Patch 01/15: Provide function to get the number of queues assigned to mdev
* vfio_ap_mdev_get_num_queues()
  ~ Changed return type to unsigned int since bitmap_weight() - used to
    get the return value - has a return type of unsigned int.

Patch 03/15: Functions to initialize/release vfio device migration data
* vfio_ap_release_mig_files()
  ~ Removed check for matrix_mdev->mig_data NULL; both callers already do
    make that check prior to making the call.

Patch 04/15: Reset migration state in VFIO_DEVICE_RESET ioctl handler
* vfio_ap_mdev_ioctl
  ~ Call vfio_ap_reset_migration_state() regardless of return from 
    vfio_ap_mdev_reset_queues() to fulfill VFIO contract that the migration
    state on reset is VFIO_DEVICE_STATE_RUNNING.

Patch 05/15: Callback to get/set vfio device mig state during guest
             migration
* vfio_ap_set_state()
  ~ Moved the container_of(vdev, struct ap_matrix_mdev, vdev) macro 
    invocation after taking the matrix_dev->mdevs_lock mutex to be
    consistent with vfio_ap_get_state()
  ~ Added ERROR check after the transition loop in vfio_ap_set_state().
    filp is set to ERR_PTR(-EIO).
    
Patch 07/15: File ops called to save the vfio device migration state
* vfio_ap_get_config()
  ~ No longer dropping the matrix_dev->mdevs_lock for call to 
    vfio_ap_store_queue_info()
* vfio_ap_stop_copy_read_parms()
  ~ Removed pos parameter from validate_stop_copy_read_parms()
    signature because it can be retrieved from the file pointer (filp) 
* vfio_ap_stop_copy_read
  ~ Put a doc block expaining the call to vfio_ap_get_config() if
    mig_file->ap_config is NULL (i.e., lazy initialization)

Patch 09/15: Add method to set a new guest AP configuration
* vfio_ap_set_new_guest_config()
  ~ Removed m_old_shadow since it is not needed
  ~ Creating new patch that make static functions non-static in this
    function which will be inserted preceding this one:
    o get_update_locks_for_mdev()
    o release_update_locks_for_mdev()
    o assert_has_update_locks_for_mdev()
    o vfio_ap_matrix_init()
    
Patch 10/15: File ops called to resume the vfio device migration
* vfio_ap_resuming_write()
  ~ Simplified by allocating a read buffer large enough to
    accommodate info for 65,535 queues rather than mulitple reallocations
  ~ Call mutex_lock(&ap_attr_mutex) followed by get_update_locks_for_mdev()
    at beginning and hold for the duration. We can have bindings or 
    queue assignments changed while updating the guest's AP configuration.
* validate_resuming_write_parms()
  ~ Changed signature to (filp, len)

Patch 11/15: Transition device migration state to STOP  
Patch 12/15: Transition device migration state from STOP to RUNNING and
             vice versa
* Squashed these two patches

Patch 14/15: Add 'migratable' feature to sysfs 'features' attribute
* features_show
  ~ Changed 'migrate' feature to 'migration'
  ~ emit a string of base features supported for SE guests; for non-SE
    guests emit the base features plus features not supported for 
    SE guests 

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 | 1494 +++++++++++++++++++++++
 drivers/s390/crypto/vfio_ap_ops.c       |  289 +++--
 drivers/s390/crypto/vfio_ap_private.h   |   75 ++
 6 files changed, 2289 insertions(+), 201 deletions(-)
 create mode 100644 drivers/s390/crypto/vfio_ap_migration.c

-- 
2.53.0


             reply	other threads:[~2026-10-09 11:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 11:42 Anthony Krowiak [this message]
2026-10-09 11:42 ` [PATCH v8 01/15] s390/vfio-ap: Provide function to get the number of queues assigned to mdev Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 02/15] s390/vfio-ap: Data structures for facilitating vfio device migration Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 03/15] s390/vfio-ap: Functions to initialize/release vfio device migration data Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 04/15] s390/vfio-ap: Reset migration state in VFIO_DEVICE_RESET ioctl handler Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 05/15] s390/vfio-ap: Callback to get/set vfio device mig state during guest migration Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 06/15] s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 07/15] s390/vfio-ap: File ops called to save the vfio device migration state Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 08/15] s390/vfio-ap: Transition device migration state from STOP to RESUMING Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 09/15] s390/vfio-ap: Prepare lock helpers and matrix init for cross-file use Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 10/15] s390/vfio-ap: Add method to set a new guest AP configuration Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 11/15] s390/vfio-ap: File ops called to resume the vfio device migration Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 12/15] s390/vfio-ap: Transition device migration state to from/to STOP Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 13/15] s390/vfio-ap: Callback to get the size of data to be migrated during guest migration Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 14/15] s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute Anthony Krowiak
2026-10-09 11:42 ` [PATCH v8 15/15] 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=20261009114244.1213173-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 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®