> 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
Exactly. It seems the code blindly enables NETIF_F_GRO_HW as long as
the
control channel is present, without verifying if the backend actually supports
the
offload features.
>
> > rtnl_unlock();
> >
> > err = virtnet_cpu_notif_add(vi);
> > --
> > 2.34.1
> >
> >
>
