Bug 1845488

Hi,

I think I understand what is happening here.
In OVS' lib/netdev-dpdk.c, we have:
static int
netdev_dpdk_vhost_client_reconfigure(struct netdev *netdev)
{
...
        if (userspace_tso_enabled()) {
            netdev->ol_flags |= NETDEV_TX_OFFLOAD_TCP_TSO;
            netdev->ol_flags |= NETDEV_TX_OFFLOAD_TCP_CKSUM;
            netdev->ol_flags |= NETDEV_TX_OFFLOAD_UDP_CKSUM;
            netdev->ol_flags |= NETDEV_TX_OFFLOAD_SCTP_CKSUM;
            netdev->ol_flags |= NETDEV_TX_OFFLOAD_IPV4_CKSUM;
            vhost_unsup_flags = 1ULL << VIRTIO_NET_F_HOST_ECN
                                | 1ULL << VIRTIO_NET_F_HOST_UFO;
        } else {
            /* This disables checksum offloading and all the features
             * that depends on it (TSO, UFO, ECN) according to virtio
             * specification. */
            vhost_unsup_flags = 1ULL << VIRTIO_NET_F_CSUM;
        }

        err = rte_vhost_driver_disable_features(dev->vhost_id,
                                                vhost_unsup_flags);

It means that depending on whether the user requests for TSO to be enabled
or not, the Virtio features advertised by the backend for the negotiation
will be different.

The problem here seems to be that the guest is not restarted between OVS
stop and start, so the guest Virtio feature negotiation is already done.
With TSO enabled, VIRTIO_NET_F_CSUM was advertised by the backend and if
the guest driver also supported it, it had been negotiated.
When disabling TSO on OVS side, this feature is no more advertised by
OVS-DPDK, which results in Qemu to rightfully fail the reconnection to
avoid undefined behaviour. Indeed, as the backend reconnection is
transparent to the guest driver it will behave with VIRTIO_NET_F_CSUM
being negotiated.

To confirm that, I think you should have below error message in the
guest's Qemu logs:

#ifdef CONFIG_VHOST_NET_USER
    if (net->nc->info->type == NET_CLIENT_DRIVER_VHOST_USER) {
        features = vhost_user_get_acked_features(net->nc);
        if (~net->dev.features & features) {
            fprintf(stderr, "vhost lacks feature mask %" PRIu64
                    " for backend\n",
                    (uint64_t)(~net->dev.features & features));
            goto fail;
        }
    }
#endif

Regards,
Maxime

Hi,

Did you had any chance to try and reproduce?
What are the Qemu logs saying?

(In reply to Maxime Coquelin from comment #1)
...
> To confirm that, I think you should have below error message in the
> guest's Qemu logs:
> 
> #ifdef CONFIG_VHOST_NET_USER
>     if (net->nc->info->type == NET_CLIENT_DRIVER_VHOST_USER) {
>         features = vhost_user_get_acked_features(net->nc);
>         if (~net->dev.features & features) {
>             fprintf(stderr, "vhost lacks feature mask %" PRIu64
>                     " for backend\n",
>                     (uint64_t)(~net->dev.features & features));

I could see this error (repeating many times) in qemu/instance.log:

2020-06-22T17:58:23.613353Z qemu-kvm: failed to init vhost_net for queue 0
vhost lacks feature mask 22529 for backend

So, all negotiated features before ovs restart are lacking now as in 22529 (0x5801).

>             goto fail;
>         }
>     }
> #endif
> 
> Regards,
> Maxime

It is not possible to enable or disable Virtio feature once the negotiation took place with the guest driver.
It this has to be done, only solution is to either hot-remove/hot-plug the Virtio device, or reboot the guest.