On 02/27/2018 04:01 PM, Michael S. Tsirkin wrote:
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?
Yes, even if I don't see a use for _ACKNOWLEDGE and _DRIVER today.
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.
Do you mean we should also notify the backend in case of NEEDS_RESET, or
clearing of FEATURES_OK?
Or you mean we should provide a way for the backend to update the device
status, e.g. by having a slave-initiated VHOST_USER_SET_VIRTIO_STATUS
request?
Thanks,
Maxime
