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

["Anthoine Bourgeois" <anthoine.bourgeois@vates.tech>]

On Fri, Jul 18, 2025 at 01:48:17PM -0700, Elliott Mitchell wrote:
>On Wed, Jul 16, 2025 at 11:31:06AM -0700, Elliott Mitchell wrote:
>> On Wed, Jul 16, 2025 at 07:47:48AM +0000, Anthoine Bourgeois wrote:
>> > On Tue, Jul 15, 2025 at 12:19:34PM -0700, Elliott Mitchell wrote:
>> > >
>> > >I tend to follow Debian, so kernel 6.1.140 and 4.17.6.  What may be
>> > >more notable is AMD processor.
>> > >
>> > >When initially reported, it was reported as being more severe on systems
>> > >with AMD processors.  I've been wondering about the reason(s) behind
>> > >that.
>> >
>> > AMD processors could make a huge difference. On Ryzen, this patch could
>> > almost double the bandwidth and on Epyc close to nothing with low
>> > frequency models, there is another bottleneck here I guess.
>> > On which one do you test?
>> >
>> > Do you know there is also a workaround on AMD processors about remapping
>> > grant tables as WriteBack?
>> > Upstream patch is 22650d605462 from XenServer.
>> > The test package for XCP-ng with the patch:
>> > https://xcp-ng.org/forum/topic/10943/network-traffic-performance-on-amd-processors
>> >
>>
>> Why are you jumping onto mostly unrelated issues when the current bug is
>> unfinished?
>>
>> Spurious events continue to be observed on the network backend.  Spurious
>> events are also being observed on block and PCI backends.  You identified
>> one cause, but others remain.
>>
>> (I'm hoping the next one effects all the back/front ends; the PCI backend
>> is a bigger issue for me)
>>
>> Should add, one VM being observed with these issue(s) is using 6.12.38.
>
>For reference, the following:
>
>for d in /sys/devices/{pci,vbd,vif}-*[0-9]-*[0-9]/xenbus
>do      if [ -f "$d/spurious_events" ]
>        then    read s < "$d/spurious_events"
>        else    s=0
>        fi
>        if [ "$s" -gt 0 ]
>        then    printf "problem %s: %d\\n" "$d/spurious_events" "$s"
>        else    printf "clean: %s\\n" "$d/spurious_events"
>        fi
>done
>
>Flags all passthrough and virtual devices.  Even though there is a
>reduction with virtual network devices, that is only a 10% reduction.
>Most of the problem remains even though there is progress.
>
>I was mentioning an AMD processor since the initial report stated the
>problem was more severe with AMD processor machines.
>
>This is likely a driver design issue.  Most pieces of hardware, telling
>the hardware to process an empty queue is quite cheap.  Perhaps minor
>energy loss, but most hardware isn't (yet) too worried about being
>attacked.
>
>Passthrough and virtual devices are quite unusual in there being a
>concern over attacks.  There could be major design flaws due to the
>front-ends being designed similar to normal drivers.
>

Hmm, you check the spurious on the backend.
Sorry I should have been more specific, this patch only mitigate the
spurious on the frontend.

I will take a look on the backend.

Regards,
Anthoine


Anthoine Bourgeois | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech