On Fri, Apr 01, 2016 at 01:16:21PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau <marcandre.lur...@redhat.com>
>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> ---
> docs/specs/vhost-user.txt | 15 +++++++++++++++
> hw/virtio/vhost-user.c | 16 ++++++++++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt
> index 8a635fa..60d6d13 100644
> --- a/docs/specs/vhost-user.txt
> +++ b/docs/specs/vhost-user.txt
> @@ -487,3 +487,18 @@ Message types
> request to the master. It is passed in the ancillary data.
> This message is only sent if VHOST_USER_PROTOCOL_F_SLAVE_CHANNEL
> feature is available.
> +
> +Slave message types
> +-------------------
> +
> + * VHOST_USER_SLAVE_SHUTDOWN:
> + Id: 1
> + Master payload: N/A
> + Slave payload: u64
> +
> + Request the master to shutdown the slave. A 0 reply is for
> + success, in which case the slave may close all connections
> + immediately and quit. A non-zero reply cancels the request.
> +
> + Before a reply comes, the master may make other requests in
> + order to flush or sync state.
Hi all,
I threw this proposal as well as DPDK's implementation to our customer
(OVS, Openstack and some other teams) who made such request before. I'm
sorry to say that none of them really liked that we can't handle crash.
Making reconnect work from a vhost-user backend crash is exactly something
they are after.
And to handle the crash, I was thinking of the proposal from Michael.
That is to do reset from the guest OS. This would fix this issue
ultimately. However, old kernel will not benefit from this, as well
as other guest other than Linux, making it not that useful for current
usage.
Thinking of that the VHOST_USER_SLAVE_SHUTDOWN just gives QEMU a chance
to get the vring base (last used idx) from the backend, Huawei suggests
that we could still make it in a consistent state after the crash, if
we get the vring base from vring->used->idx. That worked as expected
from my test. The only tricky thing might be how to detect a crash,
and we could do a simple compare of the vring base from QEMU with
the vring->used->idx at the initiation stage. If mismatch found, get
it from vring->used->idx instead.
Comments/thoughts? Is it a solid enough solution to you? If so, we
could make things much simpler, and what's most important, we could
be able to handle crash.
--yliu
