On 26.09.23 22:10, Stefan Hajnoczi wrote:
Hi Hanna,
I was thinking about how this could work without SUSPEND/RESUME. What
do you think of the following?
1. The front-end sends VHOST_USER_RESET_DEVICE (or
VHOST_USER_RESET_OWNER, when necessary) when the guest driver resets
the device but not on vhost_dev_start()/vhost_dev_stop().
This is half the work of SUSPEND/RESUME. It isn’t easy to do.
2. Suspend the device when all virtqueues are stopped via
VHOST_USER_GET_VRING_BASE. Resume the device after at least one
virtqueue is started and enabled.
3. Ignore VHOST_USER_SET_STATUS.
Reset would work. The device would suspend and resume without losing
state. Existing vhost-user backends already behave like this in
practice (they often don't implement RESET_DEVICE).
I don’t understand the point, though. Today, reset in practice is a
no-op anyway, precisely because we only send SET_STATUS 0, don’t fall
back to
RESET_OWNER/RESET_DEVICE, and no back-end implements SET_STATUS 0 as a
reset. By sending RESET_* in case of a guest-initiated reset and
nothing in case of stop/cont, we effectively don’t change anything about
the latter (which is what SUSPEND/RESUME would be for), but only fix the
former case. While I agree that it’s wrong that we don’t really reset
the back-end in case of a guest-initiated reset, this is the first time
in this whole discussion that that part has been presented as a problem
that needs fixing now.
So the proposal effectively changes nothing for the
vhost_dev_stop()/start() case where we’d want to make use of
SUSPEND/RESUME, but only for the case where we would not use it.
Hanna
_______________________________________________
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs
