get_vring_base should not reset the queue

The spec specifies that on receiving `GET_VRING_BASE` the backend should
stop the vring, but not that it must be reset. This is intended for
`VHOST_USER_RESET_DEVICE`, also in this case the spec makes a
difference between stopping and disabling the ring.

The spec also doesn't forbid to send `VHOST_USER_SET_VRING_ENABLE` to
enable the vring after receiving `GET_VRING_BASE` or sending more
`GET_VRING_BASE` messages, which would always respond 0. Moreover, qemu
doesn't reset the vring either.

Signed-off-by: German Maglione <[email protected]>

Author: germag

crates/vhost-user-backend/src/handler.rs

@@ -367,12 +367,14 @@ where
         if index as usize >= self.num_queues {
             return Err(VhostUserError::InvalidParam);
         }
+
         // Quote from vhost-user specification:
         // Client must start ring upon receiving a kick (that is, detecting
         // that file descriptor is readable) on the descriptor specified by
         // VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
         // VHOST_USER_GET_VRING_BASE.
         self.vrings[index as usize].set_queue_ready(false);
+
         if let Some(fd) = self.vrings[index as usize].get_ref().get_kick() {
             for (thread_index, queues_mask) in self.queues_per_thread.iter().enumerate() {
                 let shifted_queues_mask = queues_mask >> index;
@@ -391,14 +393,6 @@ where
         self.vrings[index as usize].set_kick(None);
         self.vrings[index as usize].set_call(None);
 
-        // Strictly speaking, we should do this upon receiving the first kick,
-        // but it's actually easier to just do it here so we're ready in case
-        // the vring gets re-initialized by the guest.
-        self.vrings[index as usize]
-            .get_mut()
-            .get_queue_mut()
-            .reset();
-
         Ok(VhostUserVringState::new(index, u32::from(next_avail)))
     }