From: sashiko-bot@kernel.org
To: "Anthony Krowiak" <akrowiak@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v10 13/15] s390/vfio-ap: Set up for vfio-ap device migration
Date: Fri, 23 Oct 2026 18:14:49 +0000 [thread overview]
Message-ID: <sashiko-outbox-183054@kernel.org> (raw)
In-Reply-To: <20261023174349.3545941-14-akrowiak@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] s390/vfio-ap: wrong SE guest check via ap_is_se_guest() on KVM host
- [Medium] s390/vfio-ap: stale completion flag and f_pos advance in vfio_ap_resuming_write()
--
commit 7adada8cbaf0b3057bf058ad4617540b9cea4ec9
Author: Anthony Krowiak <akrowiak@linux.ibm.com>
s390/vfio-ap: Set up for vfio-ap device migration
This commit wires up VFIO migration operations and sets the
VFIO_MIGRATION_STOP_COPY flag on the vfio-ap mdev during device probe to
enable live migration support.
> diff --git a/drivers/s390/crypto/vfio_ap_migration.c b/drivers/s390/crypto/vfio_ap_migration.c
> index 38098968eaa2c..660b5a21fe9e8 100644
> --- a/drivers/s390/crypto/vfio_ap_migration.c
> +++ b/drivers/s390/crypto/vfio_ap_migration.c
> @@ -212,6 +212,30 @@ static int vfio_ap_release_mig_file(struct inode *file_inode, struct file *filp)
> return 0;
> }
>
> +static const struct vfio_migration_ops vfio_ap_migration_ops;
> +
> +/**
> + * vfio_ap_setup_vfio_device_migration:
> + *
> + * Plug the object containing the function pointers to the migration callbacks
> + * required to facilitate VFIO AP migration into the mdev
> + *
> + *
> + * @matrix_mdev: pointer to object containing the mdev state
> + */
> +void vfio_ap_setup_vfio_device_migration(struct ap_matrix_mdev *matrix_mdev)
> +{
> + /*
> + * Live guest migration is not supported for SE guests, so there is no
> + * need to initialize the migration capabilities.
> + */
> + if (ap_is_se_guest())
> + return;
[Severity: High]
Does calling ap_is_se_guest() here and in vfio_ap_init_migration_data()
actually detect a Secure Execution guest on the KVM host?
In drivers/s390/crypto/ap_bus.c, ap_is_se_guest() checks whether the
currently running kernel is itself a Protected Virtualization guest:
bool ap_is_se_guest(void)
{
return is_prot_virt_guest() && ap_sb_available();
}
Since vfio_ap runs in the KVM host kernel where is_prot_virt_guest() is
always false, ap_is_se_guest() will always evaluate to false on the host.
Furthermore, at vfio_ap_mdev_probe() -> vfio_ap_setup_vfio_device_migration()
time, matrix_mdev->kvm is still NULL, and a guest only enters Protected
Virtualization mode at runtime via KVM_S390_PV_COMMAND. Should the SE guest
check instead be performed dynamically against matrix_mdev->kvm via
kvm_s390_pv_is_protected() when handling migration state transitions in
vfio_ap_set_state() or vfio_ap_transition_to_state()?
> +
> + matrix_mdev->vdev.migration_flags = VFIO_MIGRATION_STOP_COPY;
> + matrix_mdev->vdev.mig_ops = &vfio_ap_migration_ops;
> +}
[Severity: Medium]
Now that vfio_ap_migration_ops is wired up and exposes the migration stream
and state transitions to userspace, can vfio_ap_resuming_write() leave
resuming_mig_data_complete set to true or leave filp->f_pos advanced when a
write fails?
In drivers/s390/crypto/vfio_ap_migration.c:vfio_ap_resuming_write():
memcpy((char *)ap_config + *pos, kbuf, len);
*pos += len;
if (*pos >= offsetofend(struct vfio_ap_config, num_queues)) {
size_t expected_sz;
if (ap_config->num_queues > MAX_AP_QUEUES) {
ret = -EINVAL;
goto out_unlock;
}
expected_sz = sizeof(struct vfio_ap_config) +
ap_config->num_queues *
sizeof(struct vfio_ap_queue_info);
if (*pos > (loff_t)expected_sz) {
ret = -EINVAL;
goto out_unlock;
}
if (*pos == (loff_t)expected_sz) {
ret = do_post_copy_validation(matrix_mdev, ap_config);
matrix_mdev->mig_data->resuming_mig_data_complete = !ret;
}
}
If userspace writes a valid payload where *pos == expected_sz,
resuming_mig_data_complete is set to true. If userspace then issues an extra
write to the resuming FD before transitioning to VFIO_DEVICE_STATE_STOP, the
extra bytes are copied into ap_config, *pos is incremented past expected_sz,
and the function returns -EINVAL without clearing resuming_mig_data_complete.
A subsequent transition from VFIO_DEVICE_STATE_RESUMING to
VFIO_DEVICE_STATE_STOP in vfio_ap_transition_to_state() only checks
mig_data->resuming_mig_data_complete and will still succeed.
Also, when any of the checks on num_queues, expected_sz, or
do_post_copy_validation() fail, *pos has already been incremented even though
vfio_ap_resuming_write() returns an error. Should the validation happen
before advancing *pos and clear resuming_mig_data_complete on error?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261023174349.3545941-1-akrowiak@linux.ibm.com?part=13
next prev parent reply other threads:[~2026-10-23 18:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 17:43 [PATCH v10 00/15] s390/vfio-ap: Add live guest migration support Anthony Krowiak
2026-10-23 17:43 ` [PATCH v10 01/15] s390/vfio-ap: Provide function to get the number of queues assigned to mdev Anthony Krowiak
2026-10-23 18:01 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 02/15] s390/vfio-ap: Data structures for facilitating vfio device migration Anthony Krowiak
2026-10-23 17:57 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 03/15] s390/vfio-ap: Functions to initialize/release vfio device migration data Anthony Krowiak
2026-10-23 18:09 ` sashiko-bot
2026-10-26 14:04 ` Anthony Krowiak
2026-10-24 7:11 ` kernel test robot
2026-10-26 14:08 ` Anthony Krowiak
2026-10-23 17:43 ` [PATCH v10 04/15] s390/vfio-ap: Reset migration state in VFIO_DEVICE_RESET ioctl handler Anthony Krowiak
2026-10-23 17:59 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 05/15] s390/vfio-ap: Callback to get/set vfio device mig state during guest migration Anthony Krowiak
2026-10-23 18:13 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 06/15] s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY Anthony Krowiak
2026-10-23 18:07 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 07/15] s390/vfio-ap: File ops called to save the vfio device migration state Anthony Krowiak
2026-10-23 18:10 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 08/15] s390/vfio-ap: Transition device migration state from STOP to RESUMING Anthony Krowiak
2026-10-23 18:00 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 09/15] s390/vfio-ap: Prepare lock helpers and matrix init for cross-file use Anthony Krowiak
2026-10-23 17:57 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 10/15] s390/vfio-ap: File ops called to resume the vfio device migration Anthony Krowiak
2026-10-23 18:15 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 11/15] s390/vfio-ap: Transition device migration state to from/to STOP Anthony Krowiak
2026-10-23 18:13 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 12/15] s390/vfio-ap: Callback to get the size of data to be migrated during guest migration Anthony Krowiak
2026-10-23 18:04 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 13/15] s390/vfio-ap: Set up for vfio-ap device migration Anthony Krowiak
2026-10-23 18:14 ` sashiko-bot [this message]
2026-10-23 17:43 ` [PATCH v10 14/15] s390/vfio-ap: Add 'migration' feature to sysfs 'features' attribute Anthony Krowiak
2026-10-23 18:06 ` sashiko-bot
2026-10-23 17:43 ` [PATCH v10 15/15] s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst Anthony Krowiak
2026-10-23 18:09 ` 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=sashiko-outbox-183054@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.