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
>
>


Reply via email to