VDUSE do not forward the enable message to the userland device at the
moment, leaving the dataplane disabled.  As there is no functional
difference if the device have no CVQ, enable them before DRIVER_OK in
that case.

For devices with a control vq, keep the enabling of the dataplane after
CVQ so QEMU can restore the device configuration.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Fixes: 6c4825476a43 ("vdpa: move vhost_vdpa_set_vring_ready to the caller")
---
 net/vhost-vdpa.c | 30 ++++++++++--------------------
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index 3df6091274e5..ee7eb1a4db28 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -397,6 +397,7 @@ static int vhost_vdpa_net_data_start(NetClientState *nc)
 {
     VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
     struct vhost_vdpa *v = &s->vhost_vdpa;
+    bool has_cvq = v->dev->vq_index_end % 2;
 
     assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
 
@@ -406,6 +407,15 @@ static int vhost_vdpa_net_data_start(NetClientState *nc)
         v->shadow_vqs_enabled = false;
     }
 
+    if (!has_cvq) {
+        for (int i = 0; i < v->dev->nvqs; ++i) {
+            int ret = vhost_vdpa_set_vring_ready(v, i + v->dev->vq_index);
+            if (ret < 0) {
+                return ret;
+            }
+        }
+    }
+
     if (v->index == 0) {
         v->shared->shadow_data = v->shadow_vqs_enabled;
         vhost_vdpa_net_data_start_first(s);
@@ -415,25 +425,6 @@ static int vhost_vdpa_net_data_start(NetClientState *nc)
     return 0;
 }
 
-static int vhost_vdpa_net_data_load(NetClientState *nc)
-{
-    VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
-    struct vhost_vdpa *v = &s->vhost_vdpa;
-    bool has_cvq = v->dev->vq_index_end % 2;
-
-    if (has_cvq) {
-        return 0;
-    }
-
-    for (int i = 0; i < v->dev->nvqs; ++i) {
-        int ret = vhost_vdpa_set_vring_ready(v, i + v->dev->vq_index);
-        if (ret < 0) {
-            return ret;
-        }
-    }
-    return 0;
-}
-
 static void vhost_vdpa_net_client_stop(NetClientState *nc)
 {
     VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
@@ -450,7 +441,6 @@ static NetClientInfo net_vhost_vdpa_info = {
         .size = sizeof(VhostVDPAState),
         .receive = vhost_vdpa_receive,
         .start = vhost_vdpa_net_data_start,
-        .load = vhost_vdpa_net_data_load,
         .stop = vhost_vdpa_net_client_stop,
         .cleanup = vhost_vdpa_cleanup,
         .has_vnet_hdr = vhost_vdpa_has_vnet_hdr,
-- 
2.53.0

On Thu, Mar 5, 2026 at 1:39 AM Eugenio Pérez <eperezma@redhat.com> wrote:
>
> VDUSE do not forward the enable message to the userland device at the
> moment, leaving the dataplane disabled.  As there is no functional
> difference if the device have no CVQ, enable them before DRIVER_OK in
> that case.
>
> For devices with a control vq, keep the enabling of the dataplane after
> CVQ so QEMU can restore the device configuration.
>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> Fixes: 6c4825476a43 ("vdpa: move vhost_vdpa_set_vring_ready to the caller")

Once we add cvq in the future, it looks like we need to bring this back?

Thanks

On Mon, Mar 9, 2026 at 9:21 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Thu, Mar 5, 2026 at 1:39 AM Eugenio Pérez <eperezma@redhat.com> wrote:
> >
> > VDUSE do not forward the enable message to the userland device at the
> > moment, leaving the dataplane disabled.  As there is no functional
> > difference if the device have no CVQ, enable them before DRIVER_OK in
> > that case.
> >
> > For devices with a control vq, keep the enabling of the dataplane after
> > CVQ so QEMU can restore the device configuration.
> >
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > Fixes: 6c4825476a43 ("vdpa: move vhost_vdpa_set_vring_ready to the caller")
>
> Once we add cvq in the future, it looks like we need to bring this back?
>

Do you mean when we add CVQ in VDUSE? I'd prefer to handle this as a
patch independent from the vdpa backend, as I'm not sure if any other
device in the wild supports the current behavior.

Considering the conversations about adding this ioctl in vhost_vdpa,
and the patch vdpa_blk needed to restore ENABLE before DRIVER_OK, I
prefer to view this as "Restore the original QEMU behavior from before
introducing CVQ shadowing." This way, no device sees a breaking change
from previous QEMU versions or even standard VirtIO. In other words,
the behavior after merging this patch is guaranteed to be supported by
all the devices, but we have seen that some devices do not support the
initialization that happens in QEMU master.

But yes, the main use case I'm testing is VDUSE+DPDK.

On Mon, Mar 9, 2026 at 4:33 PM Eugenio Perez Martin <eperezma@redhat.com> wrote:
>
> On Mon, Mar 9, 2026 at 9:21 AM Jason Wang <jasowang@redhat.com> wrote:
> >
> > On Thu, Mar 5, 2026 at 1:39 AM Eugenio Pérez <eperezma@redhat.com> wrote:
> > >
> > > VDUSE do not forward the enable message to the userland device at the
> > > moment, leaving the dataplane disabled.  As there is no functional
> > > difference if the device have no CVQ, enable them before DRIVER_OK in
> > > that case.
> > >
> > > For devices with a control vq, keep the enabling of the dataplane after
> > > CVQ so QEMU can restore the device configuration.
> > >
> > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > Fixes: 6c4825476a43 ("vdpa: move vhost_vdpa_set_vring_ready to the caller")
> >
> > Once we add cvq in the future, it looks like we need to bring this back?
> >
>
> Do you mean when we add CVQ in VDUSE? I'd prefer to handle this as a
> patch independent from the vdpa backend, as I'm not sure if any other
> device in the wild supports the current behavior.

Yes.

>
> Considering the conversations about adding this ioctl in vhost_vdpa,
> and the patch vdpa_blk needed to restore ENABLE before DRIVER_OK, I
> prefer to view this as "Restore the original QEMU behavior from before
> introducing CVQ shadowing." This way, no device sees a breaking change
> from previous QEMU versions or even standard VirtIO. In other words,
> the behavior after merging this patch is guaranteed to be supported by
> all the devices, but we have seen that some devices do not support the
> initialization that happens in QEMU master.
>
> But yes, the main use case I'm testing is VDUSE+DPDK.

Ok.

So,

Acked-by: Jason Wang <jasowang@redhat.com>

Thanks
>