Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Anthony Krowiak" <akrowiak@linux.ibm.com>
Cc: "Vasily Gorbik" <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH v5 14/15] s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute
Date: Fri, 24 Jul 2026 18:30:10 +0000	[thread overview]
Message-ID: <20260724183010.DC3121F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724161351.1802644-15-akrowiak@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added 'migratable' feature is not documented in the Driver Features table, and the Limitations section explicitly states migration is not supported.
--

--- Patch [14]: [PATCH v5 14/15] s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute ---
commit c8392bd6bcb1403c66327e9551bbba5ecd4a167d
Author: Anthony Krowiak <akrowiak@linux.ibm.com>

s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute

This commit adds the 'migratable' feature to the sysfs features attribute
for vfio_ap. This exposes the feature to userspace, indicating that
migration of vfio devices is supported.

> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index 8e69ed286bb9c..4e973736522bc 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -26,9 +26,11 @@ MODULE_LICENSE("GPL v2");
>  struct ap_matrix_dev *matrix_dev;
>  debug_info_t *vfio_ap_dbf_info;
>  
> +#define FEATURES "guest_matrix hotplug ap_config migratable"

[Severity: Low]
Since this adds the 'migratable' feature, shouldn't
Documentation/arch/s390/vfio-ap.rst be updated to reflect this capability?

Looking at that file, the "Driver Features" table appears to be missing an
entry for this newly added 'migratable' flag.

Additionally, the "Limitations" section in the same document explicitly
states: "Live guest migration is not supported for guests using AP devices
without intervention by a system administrator."

Does this patch series render that limitation obsolete? If so, should that
section be updated or removed to avoid confusing users?

> +
>  static ssize_t features_show(struct device *dev, struct device_attribute *attr, char *buf)
>  {
> -	return sysfs_emit(buf, "guest_matrix hotplug ap_config\n");
> +	return sysfs_emit(buf, "%s\n", FEATURES);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724161351.1802644-1-akrowiak@linux.ibm.com?part=14

  reply	other threads:[~2026-07-24 18:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 16:13 [PATCH v5 00/15] s390/vfio-ap: Add live guest migration support Anthony Krowiak
2026-07-24 16:13 ` [PATCH v5 01/15] s390/vfio-ap: Provide function to get the number of queues assigned to mdev Anthony Krowiak
2026-07-24 17:36   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 02/15] s390/vfio-ap: Data structures for facilitating vfio device migration Anthony Krowiak
2026-07-24 17:28   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 03/15] s390/vfio-ap: Functions to initialize/release vfio device migration data Anthony Krowiak
2026-07-24 17:35   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 04/15] s390/vfio-ap: Reset migration state in VFIO_DEVICE_RESET ioctl handler Anthony Krowiak
2026-07-24 17:43   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 05/15] s390-vfio-ap: Callback to get/set vfio device mig state during guest migration Anthony Krowiak
2026-07-24 17:47   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 06/15] s390/vfio-ap: Transition guest migration state from STOP to STOP_COPY Anthony Krowiak
2026-07-24 17:50   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 07/15] s390/vfio-ap: File ops called to save the vfio device migration state Anthony Krowiak
2026-07-24 18:04   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 08/15] s390/vfio-ap: Transition device migration state from STOP to RESUMING Anthony Krowiak
2026-07-24 18:06   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 09/15] s390/vfio-ap: Add method to set a new guest AP configuration Anthony Krowiak
2026-07-24 18:10   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 10/15] s390/vfio-ap: File ops called to resume the vfio device migration Anthony Krowiak
2026-07-24 18:17   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 11/15] s390/vfio-ap: Transition device migration state to STOP Anthony Krowiak
2026-07-24 18:26   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 12/15] s390/vfio-ap: Transition device migration state from STOP to RUNNING and vice versa Anthony Krowiak
2026-07-24 18:29   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 13/15] s390/vfio-ap: Callback to get the size of data to be migrated during guest migration Anthony Krowiak
2026-07-24 18:27   ` sashiko-bot
2026-07-24 16:13 ` [PATCH v5 14/15] s390/vfio-ap: Add 'migratable' feature to sysfs 'features' attribute Anthony Krowiak
2026-07-24 18:30   ` sashiko-bot [this message]
2026-07-24 16:13 ` [PATCH v5 15/15] s390/vfio-ap: Add live guest migration chapter to vfio-ap.rst Anthony Krowiak
2026-07-24 18:38   ` 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=20260724183010.DC3121F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=akrowiak@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox