Fix return value of GET_VRING_BASE message

[germag]

Summary of the PR

When the frontend sends the GET_VRING_BASE message, we should return the vring's last available index and stop the vring. Commit 1713135 reset the vring upon receiving GET_VRING_BASE, But to return the correct index we should not reset the queue before getting its value, otherwise we will always return 0.

Note:
Neither qemu[0] nor dpdk[1] reset the vring when receiving GET_VRING_BASE

[0] https://github.com/qemu/qemu/blob/792f77f376adef944f9a03e601f6ad90c2f891b2/subprojects/libvhost-user/libvhost-user.c#L1175

[1] https://github.com/DPDK/dpdk/blob/d03446724972d2a1bb645ce7f3e64f5ef0203d61/lib/vhost/vhost_user.c#L2133

[stefano-garzarella]

LGTM, but I wonder whether we should now call reset() for example in set_owner() or reset_owner()

[germag]

LGTM, but I wonder whether we should now call reset() for example in set_owner() or reset_owner()

According to the spec RESET_OWNER is deprecated:

This is no longer used. Used to be sent to request disabling all rings, but some back-ends interpreted it to also discard connection state (this interpretation would lead to bugs). It is recommended that back-ends either ignore this message, or use it to disable all rings.

Not sure about doing in SET_OWNER qemu already set a bunch of stuff before sending SET_OWNER, same for the first kick (mentioned in the reset comment). The spec says we should stop the vring, but not resetting it, and the vring is initialized when we add the memory regions, so not sure if we should keep the reset(), btw neither qemu[0] nor dpdk[1] reset the vring when receiving GET_VRING_BASE, @slp wdyt?

[0] https://github.com/qemu/qemu/blob/792f77f376adef944f9a03e601f6ad90c2f891b2/subprojects/libvhost-user/libvhost-user.c#L1175

[1] https://github.com/DPDK/dpdk/blob/d03446724972d2a1bb645ce7f3e64f5ef0203d61/lib/vhost/vhost_user.c#L2133

[stefano-garzarella]

According to the spec RESET_OWNER is deprecated:

I see, thanks for checking!

Not sure about doing in SET_OWNER qemu already set a bunch of stuff before sending SET_OWNER, same for the first kick (mentioned in the reset comment). The spec says we should stop the vring, but not resetting it, and the vring is initialized when we add the memory regions, so not sure if we should keep the reset(), btw neither qemu[0] nor dpdk[1] reset the vring when receiving GET_VRING_BASE, @slp wdyt?

Okay, the current version leaves reset() and fetches the next_avail before it. This LGTM, but I think your first version (avoid to call reset() and just call set_ready(false)) was okay, since it seems libvhost-user does the same.

Anyway, I'd wait @slp since that change was part of rust-vmm/vhost-user-backend#18

[germag]

(Sorry, I forgot to comment the diff between v1 and v2)

v2:

• Get the last available index before changing the vring state
• Keep the call to reset() instead of set_ready(false)

[stefano-garzarella]

@jiangliu are you okay with resetting the vring?

As pointed out by German, neither qemu's libvhost-user nor dpdk reset the vring when receiving GET_VRING_BASE.

[jiangliu]

@jiangliu are you okay with resetting the vring?

As pointed out by German, neither qemu's libvhost-user nor dpdk reset the vring when receiving GET_VRING_BASE.

It would be safer to keep the same behavior as qemu/libvhost-user:)

[slp]

Current version LGTM.

[stefano-garzarella]

Current version LGTM.

It's not clear to me though why we have to reset the whole VQ, would it be better just to stop it?

[stefano-garzarella]

So, let's merge this version that should have less impact, then we can try to figure out if we can avoid resetting the VQ and if we need to move that call in some other place

[slp]

Current version LGTM.

It's not clear to me though why we have to reset the whole VQ, would it be better just to stop it?

I'm honestly not sure, but I'd prefer to cut a release without altering that behavior, and then consider a different approach (along with things like #155) in the next one. Sounds reasonable?

[stefano-garzarella]

Current version LGTM.

It's not clear to me though why we have to reset the whole VQ, would it be better just to stop it?

I'm honestly not sure, but I'd prefer to cut a release without altering that behavior, and then consider a different approach (along with things like #155) in the next one. Sounds reasonable?

Yep, same conclusion #154 (comment) :-)