On Fri, Feb 16, 2018 at 06:29:07PM +0100, Maxime Coquelin wrote: > diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt > index 9fcf48d611..daa452bd36 100644 > --- a/docs/interop/vhost-user.txt > +++ b/docs/interop/vhost-user.txt > @@ -368,6 +368,7 @@ Protocol features > #define VHOST_USER_PROTOCOL_F_MTU 4 > #define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5 > #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN 6 > +#define VHOST_USER_PROTOCOL_F_VIRTIO_STATUS 7 > > Master message types > -------------------- > @@ -663,6 +664,19 @@ Master message types > field, and slaves MUST NOT accept SET_CONFIG for read-only > configuration space fields unless the live migration bit is set. > > +* VHOST_USER_SET_VIRTIO_STATUS > + > + Id: 26 > + Equivalent ioctl: N/A > + Master payload: u64 > + Slave payload: N/A > + > + Sent by the vhost-user master to notify of virtio device status change. > + The payload is a u64 representing the virtio device status as defined > in > + the virtio specification. > + The request should be sent only when > VHOST_USER_PROTOCOL_F_VIRTIO_STATUS > + protocol feature has been negotiated. > + > Slave message types > ------------------- >
So for now backend was only activated after DRIVER_OK. Does this message mean that we must send updates such as _DRIVER as well? Further, this is kind of one-way, but there are several cases where device modifies the status. One is NEEDS_RESET. Another is clearing of FEATURES_OK. -- MST