From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
kvm@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [GIT PULL v1 05/23] s390/vfio_ccw: Calculate idal length based on idaw type
Date: Mon, 03 Aug 2026 16:24:46 +0000 [thread overview]
Message-ID: <20260803162447.EFC2F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260803160924.236807-6-imbrenda@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Untranslated guest physical addresses (or garbage data) are passed to the physical host channel subsystem for skipped commands, causing spurious channel-program checks.
--
--- Patch [5]: [GIT PULL v1 05/23] s390/vfio_ccw: Calculate idal length based on idaw type ---
commit e748c56d38e70498395b0ca91606fb9902835452
Author: Eric Farman <farman@linux.ibm.com>
s390/vfio_ccw: Calculate idal length based on idaw type
This commit fixes the guest IDAL length calculation in get_guest_idal() by
ensuring the size is based on the IDAW type (Format-1 vs Format-2) rather
than unconditionally assuming Format-2 (64-bit).
Link: https://lore.kernel.org/r/20260720203400.7328E1F000E9@smtp.kernel.org/
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index 6275794751cb4..5ef082b8289af 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -233,6 +233,7 @@ static void convert_ccw0_to_ccw1(struct ccw1 *source, unsigned long len)
> }
>
> #define idal_is_2k(_cp) (!(_cp)->orb.cmd.c64 || (_cp)->orb.cmd.i2k)
> +#define get_idaw_size(_cp) ((_cp)->orb.cmd.c64 ? sizeof(u64) : sizeof(u32))
>
> /*
> * Helpers to operate ccwchain.
[ ... ]
> @@ -593,7 +594,7 @@ static int ccw_count_idaws(struct ccw1 *ccw,
> struct vfio_device *vdev =
> &container_of(cp, struct vfio_ccw_private, cp)->vdev;
> u64 iova;
> - int size = cp->orb.cmd.c64 ? sizeof(u64) : sizeof(u32);
> + int size = get_idaw_size(cp);
> int ret;
> int bytes = 1;
[Severity: High]
This is a pre-existing issue, but looking at ccwchain_fetch_ccw() in this
same file, there appears to be a problem when evaluating skipped commands:
drivers/s390/cio/vfio_ccw_cp.c:ccwchain_fetch_ccw() {
...
if (ccw_does_data_transfer(ccw)) {
ret = page_array_pin(pa, vdev, idal_is_2k(cp));
if (ret < 0)
goto out_unpin;
} else {
pa->pa_nr = 0;
}
ccw->cda = virt_to_dma32(idaws);
ccw->flags |= CCW_FLAG_IDA;
/* Populate the IDAL with pinned/translated addresses from page */
page_array_idal_create_words(pa, idaws);
...
}
When pa->pa_nr is 0 for a command that does not transfer data (such as a
read with the SKIP flag set), page_array_idal_create_words() will perform
no operations.
Since ccw->cda is unconditionally set to the idaws array and CCW_FLAG_IDA
is set, does this cause the host channel subsystem to fetch untranslated
guest physical addresses (or garbage data)?
For skipped read operations, the s390 hardware architecture still requires
IDAWs to be fetched and validity checked. Could this result in spurious
channel-program checks being injected into valid guest I/O operations?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803160924.236807-1-imbrenda@linux.ibm.com?part=5
next prev parent reply other threads:[~2026-08-03 16:24 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 16:09 [GIT PULL v1 00/23] KVM: s390: Misc KVM and vfio-ccw fixes Claudio Imbrenda
2026-08-03 16:09 ` [GIT PULL v1 01/23] s390/vfio_ccw: Free all memory if cp_init() fails Claudio Imbrenda
2026-08-03 16:28 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 02/23] s390/vfio_ccw: Limit the number of channel program segments Claudio Imbrenda
2026-08-03 16:32 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 03/23] s390/vfio_ccw: Fix out of bounds check on CCW array Claudio Imbrenda
2026-08-03 16:09 ` [GIT PULL v1 04/23] s390/vfio_ccw: Ensure first IDAW remains constant Claudio Imbrenda
2026-08-03 16:24 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 05/23] s390/vfio_ccw: Calculate idal length based on idaw type Claudio Imbrenda
2026-08-03 16:24 ` sashiko-bot [this message]
2026-08-03 16:09 ` [GIT PULL v1 06/23] s390/vfio_ccw: Ensure index for read/write regions are within range Claudio Imbrenda
2026-08-03 16:34 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 07/23] s390/vfio_ccw: Cancel existing workqueues Claudio Imbrenda
2026-08-03 16:41 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 08/23] s390/vfio_ccw: Move cp cleanup out of not operational Claudio Imbrenda
2026-08-03 16:39 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 09/23] s390/vfio_ccw: Selectively expand io_mutex Claudio Imbrenda
2026-08-03 16:54 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 10/23] s390/vfio_ccw: Implement a crw lock Claudio Imbrenda
2026-08-03 16:51 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 11/23] KVM: s390: Fix unlikely NULL gmap dereference Claudio Imbrenda
2026-08-03 16:43 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 12/23] KVM: s390: Do not free SCA if it was not allocated Claudio Imbrenda
2026-08-03 16:49 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 13/23] KVM: s390: Fix kvm_s390_vcpu_unsetup_cmma() Claudio Imbrenda
2026-08-03 16:54 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 14/23] KVM: s390: Fix overclearing ESCA in case of error Claudio Imbrenda
2026-08-03 17:03 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 15/23] KVM: s390: ucontrol: Fix sca_clear_ext_call() Claudio Imbrenda
2026-08-03 17:09 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 16/23] KVM: s390: Fix leaking of PGM_ADDRESSING to userspace Claudio Imbrenda
2026-08-03 17:14 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 17/23] KVM: s390: Fix race in __do_essa() Claudio Imbrenda
2026-08-03 17:04 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 18/23] KVM: s390: cmma: Fix dirty tracking when removing memslot Claudio Imbrenda
2026-08-03 17:12 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 19/23] KVM: s390: ucontrol: Add missing locking around gmap_remove_child() Claudio Imbrenda
2026-08-03 17:19 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 20/23] KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails Claudio Imbrenda
2026-08-03 17:13 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 21/23] KVM: s390: Return -EINTR if a signal is pending while faulting-in Claudio Imbrenda
2026-08-03 17:40 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 22/23] KVM: s390: Fix ordering when adding to SCA Claudio Imbrenda
2026-08-03 17:26 ` sashiko-bot
2026-08-03 16:09 ` [GIT PULL v1 23/23] KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu() Claudio Imbrenda
2026-08-03 17:19 ` sashiko-bot
2026-08-06 13:48 ` [GIT PULL v1 00/23] KVM: s390: Misc KVM and vfio-ccw fixes Paolo Bonzini
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=20260803162447.EFC2F1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@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