From: sashiko-bot@kernel.org
To: "Josh Hilke" <jrhilke@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v4 5/9] vfio: selftests: igb: Extend memcpy completion timeout for line-rate hardware
Date: Fri, 10 Jul 2026 22:24:41 +0000 [thread overview]
Message-ID: <20260710222441.A84191F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710-igb_v3_b4-v4-5-56e7e2576cc1@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The selftest driver permanently desynchronizes its RX ring from the hardware upon encountering a dropped TX packet, leading to cascading test failures.
--
--- Patch [5]: [PATCH v4 5/9] vfio: selftests: igb: Extend memcpy completion timeout for line-rate hardware ---
commit 5b4ec7eb56b488ee6f3c3a7fb697c298ba1953f4
Author: Alex Williamson <alex.williamson@nvidia.com>
vfio: selftests: igb: Extend memcpy completion timeout for line-rate hardware
This commit increases the timeout in the igb driver selftest to wait for RX
descriptor writeback. It adjusts the wait time from 1 ms to up to 200 ms to
account for line-rate processing on real 82576 hardware. This provides enough
headroom for legitimate transfers to complete while keeping invalid-DMA tests
bounded.
> diff --git a/tools/testing/selftests/vfio/lib/drivers/igb/igb.c b/tools/testing/selftests/vfio/lib/drivers/igb/igb.c
> index cd51a72b0e7fa..172c95cea3c8a 100644
> --- a/tools/testing/selftests/vfio/lib/drivers/igb/igb.c
> +++ b/tools/testing/selftests/vfio/lib/drivers/igb/igb.c
> @@ -428,12 +428,23 @@ static int igb_memcpy_wait(struct vfio_pci_device *device)
> prev_tail = (igb->rx_tail + RING_SIZE - 1) % RING_SIZE;
> rx = &igb->rx_ring[prev_tail];
>
> - retries = 100;
> + /*
> + * Real 82576 hardware processes the descriptor ring at line rate.
> + * max_memcpy_size = (RING_SIZE - 1) * IGB_MAX_CHUNK_SIZE ~= 4 MB,
> + * split into 4095 1 KB frames. At 1 Gb/s (~125 MB/s) the worst
> + * valid memcpy takes ~32 ms on the wire, plus per-frame preamble,
> + * SFD, IFG and FCS overhead (~3%) and descriptor fetch/writeback
> + * latency. Wait up to ~200 ms before declaring the device hung;
> + * ~6x the line-rate floor leaves comfortable headroom for host
> + * scheduling jitter while keeping the intentional invalid-DMA
> + * tests bounded.
> + */
> + retries = 200;
> while (retries-- > 0) {
> status = le32_to_cpu(READ_ONCE(rx->wb.status_error));
> if (status & 1)
> break;
> - usleep(10);
> + usleep(1000);
> }
>
> if (status & 1)
[Severity: Medium]
When the intentional invalid-DMA tests timeout, does the software RX ring
become permanently desynchronized from the hardware?
In igb_memcpy_start(), the software rx_tail is unconditionally advanced:
tools/testing/selftests/vfio/lib/drivers/igb/igb.c:igb_memcpy_start() {
...
igb->tx_tail = (igb->tx_tail + 1) % RING_SIZE;
igb->rx_tail = (igb->rx_tail + 1) % RING_SIZE;
...
}
During an intentional invalid DMA (like in the mix_and_match test), the IOMMU
blocks the TX fetch and the packet is dropped, so the hardware RX ring never
advances.
When igb_memcpy_wait() times out, it returns -ETIMEDOUT but leaves the
software rx_tail out of sync with the hardware RDH.
Could this cause all subsequent valid test loopbacks to fail because they
wait on the wrong descriptor slot?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-igb_v3_b4-v4-0-56e7e2576cc1@google.com?part=5
next prev parent reply other threads:[~2026-07-10 22:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 22:06 [PATCH v4 0/9] vfio: selftests: Add driver for Intel Ethernet Gigabit Controller (IGB) Josh Hilke
2026-07-10 22:06 ` [PATCH v4 1/9] vfio: selftests: igb: Add driver for IGB QEMU device Josh Hilke
2026-07-10 22:19 ` sashiko-bot
2026-07-13 19:45 ` Josh Hilke
2026-07-10 22:06 ` [PATCH v4 2/9] vfio: selftests: igb: Use PHY internal loopback on 82576 Josh Hilke
2026-07-10 22:06 ` [PATCH v4 3/9] vfio: selftests: igb: Use advanced TX and RX descriptors Josh Hilke
2026-07-10 22:06 ` [PATCH v4 4/9] vfio: selftests: igb: Program MSI-X interrupt routing Josh Hilke
2026-07-10 22:23 ` sashiko-bot
2026-07-10 22:06 ` [PATCH v4 5/9] vfio: selftests: igb: Extend memcpy completion timeout for line-rate hardware Josh Hilke
2026-07-10 22:24 ` sashiko-bot [this message]
2026-07-10 22:06 ` [PATCH v4 6/9] vfio: selftests: igb: Disable PCIe completion timeout retries Josh Hilke
2026-07-10 22:06 ` [PATCH v4 7/9] vfio: selftests: Add helpers to re-enable interrupts Josh Hilke
2026-07-10 22:06 ` [PATCH v4 8/9] vfio: selftests: igb: Factor hardware programming into igb_hw_init() Josh Hilke
2026-07-10 22:06 ` [PATCH v4 9/9] vfio: selftests: igb: Recover after DMA-read faults Josh Hilke
2026-07-10 22:33 ` 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=20260710222441.A84191F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jrhilke@google.com \
--cc=kvm@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.