If a program in host communicates with a vsock device in guest via 'vsock://', but the device is not ready, the 'connect' syscall will block and then timeout after 2 second default.(the timeout is defined in kernel: #define VSOCK_DEFAULT_CONNECT_TIMEOUT (2 * HZ)). We can avoid this case if qemu reports an event when the vsock is ready and the program waits the event before connecting.
Report vsock running event so that the upper application can control boot sequence. see https://github.com/kata-containers/runtime/pull/1918 Signed-off-by: Ning Bo <ning....@zte.com.cn> --- v2: fix typo --- hw/virtio/vhost-vsock.c | 3 +++ qapi/char.json | 22 ++++++++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c index 0371493..a5920fd 100644 --- a/hw/virtio/vhost-vsock.c +++ b/hw/virtio/vhost-vsock.c @@ -22,6 +22,7 @@ #include "qemu/iov.h" #include "qemu/module.h" #include "monitor/monitor.h" +#include "qapi/qapi-events-char.h" enum { VHOST_VSOCK_SAVEVM_VERSION = 0, @@ -68,6 +69,8 @@ static int vhost_vsock_set_running(VHostVSock *vsock, int start) if (ret < 0) { return -errno; } + qapi_event_send_vsock_running(vsock->conf.guest_cid, start != 0); + return 0; } diff --git a/qapi/char.json b/qapi/char.json index a6e81ac..4cfbcf2 100644 --- a/qapi/char.json +++ b/qapi/char.json @@ -570,3 +570,25 @@ { 'event': 'VSERPORT_CHANGE', 'data': { 'id': 'str', 'open': 'bool' } } + +## +# @VSOCK_RUNNING: +# +# Emitted when the guest changes the vsock status. +# +# @cid: guest context ID +# +# @running: true if the vsock is running +# +# Since: 4.2 +# +# Example: +# +# <- { "event": "VSOCK_RUNNING", +# "data": { "cid": "123456", "running": true }, +# "timestamp": { "seconds": 1401385907, "microseconds": 422329 } } +# +## +{ 'event': 'VSOCK_RUNNING', + 'data': { 'cid': 'uint64', + 'running': 'bool' } } -- 2.9.5
