Re: [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility

[Cornelia Huck <cohuck@redhat.com>]

On Tue, Jul 06 2021, Jason Wang <jasowang@redhat.com> wrote:

> This patch adds new device facility to save and restore virtqueue
> state. The virtqueue state is split into two parts:
>
> - The available state: The state that is used for read the next
>   available buffer.
> - The used state: The state that is used for making buffer used.
>
> Note that, there could be devices that is required to set and get the
> requests that are being processed by the device. I leave such API to
> be device specific.
>
> This facility could be used by both migration and device diagnostic.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  content.tex | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 117 insertions(+)

> +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State}
> +
> +If VIRTIO_F_RING_STATE has not been negotiated, a device MUST ingore
> +the read and write to the virtqueue state.
> +
> +If VIRTIO_F_RING_STATE has been negotiated:
> +\begin{itemize}
> +\item A device SHOULD ignore the write to the virtqueue state if the
> +FEATURE_OK status bit is not set.
> +\item A device SHOULD ignore the write to the virtqueue state if the
> +DRIVER_OK status bit is set.
> +\end{itemize}
> +
> +If VIRTIO_F_RING_STATE has been negotiated, a device MAY has its
> +device-specific way for the driver to set and get extra virtqueue
> +states such as in flight requests.

Maybe better

"If VIRTIO_F_RING_STATE has been negotiated, a device MAY provide a
device-specific mechanism to set and get extra virtqueue states such as
in flight reqeuests."

If a device type supports this facility, does it imply that it is always
present when VIRTIO_RING_STATE has been negotiated? I guess it could
define further device-specific features to make it more configurable.