qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 2/5] vhost-user: Introduce new request to send vir


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC 2/5] vhost-user: Introduce new request to send virtio device status
Date: Tue, 27 Feb 2018 17:01:28 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]