irt: [PATCH v2] xen/netfront: Fix TX response spurious interrupts

[Elliott Mitchell <ehem+xen@xxxxxxx>]

Trimming Cc list a bit since this follow-up topic doesn't need quite as
wide distribution.

On Tue, Jul 15, 2025 at 04:11:29PM +0000, Anthoine Bourgeois wrote:
> We found at Vates that there are lot of spurious interrupts when
> benchmarking the PV drivers of Xen. This issue appeared with a patch
> that addresses security issue XSA-391 (see Fixes below). On an iperf
> benchmark, spurious interrupts can represent up to 50% of the
> interrupts.

<snip>

> Moreover, this problem is amplifyed by the penalty imposed by a spurious
> interrupt. When an interrupt is found spurious the interrupt chip will
> delay the EOI to slowdown the backend. This delay will allow more
> responses to be handled by the request path and then there will be more
> chance the next interrupt will not find any work to do, creating a new
> spurious interrupt.

When this was first discovered the problem was reported as being more
severe on systems with AMD processors and less severe on systems with
Intel processors.

Have you been able to look deeper to analyze the reason for this?

I wonder whether that difference might point to some deeper issue.
Latency in interrupt handling/propogation causing problems?  There are a
few other bugs which could be explained by issues with interrupts.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445