On Fri, Mar 13, 2026 at 9:37 AM Di Zhu <[email protected]> wrote:
>
> Although VIRTIO_NET_F_CTRL_GUEST_OFFLOADS is negotiated, which indicates
> the device supports dynamic control of guest offloads, it does not
> necessarily mean the device supports specific hardware GRO features.
>
> If none of the features defined in GUEST_OFFLOAD_GRO_HW_MASK (such as
> TSO4, TSO6, or UFO) are present in vi->guest_offloads_capable, the
> device effectively lacks the hardware capability to perform GRO.
>
> In this case, NETIF_F_GRO_HW should be cleared from dev->hw_features
> to prevent the stack from attempting to enable an unsupported
> hardware offload configuration.
>
> Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO")
> Signed-off-by: Di Zhu <[email protected]>
> ---
> drivers/net/virtio_net.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 72d6a9c6a5a2..49a60af684d5 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -7058,6 +7058,9 @@ static int virtnet_probe(struct virtio_device *vdev)
> }
> vi->guest_offloads_capable = vi->guest_offloads;
>
> + if (!(vi->guest_offloads_capable & GUEST_OFFLOAD_GRO_HW_MASK))
> + dev->hw_features &= ~NETIF_F_GRO_HW;
> +
It looks to me the root cause is this during probe?
if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS))
dev->hw_features |= NETIF_F_GRO_HW;
Thanks
> rtnl_unlock();
>
> err = virtnet_cpu_notif_add(vi);
> --
> 2.34.1
>
>