Re: [PATCH V2 4/6] virtio-pci: implement VIRTIO_F_QUEUE_STATE

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Nov 13, 2023 at 05:29:51PM +0800, Zhu, Lingshan wrote:
> 
> 
> On 11/9/2023 1:56 AM, Michael S. Tsirkin wrote:
> > On Fri, Nov 03, 2023 at 06:34:35PM +0800, Zhu Lingshan wrote:
> > > This patch adds two new le16 fields to common configuration structure
> > > to support VIRTIO_F_QUEUE_STATE in PCI transport layer.
> > > 
> > > Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
> > > ---
> > >   transport-pci.tex | 18 ++++++++++++++++++
> > >   1 file changed, 18 insertions(+)
> > > 
> > > diff --git a/transport-pci.tex b/transport-pci.tex
> > > index a5c6719..3161519 100644
> > > --- a/transport-pci.tex
> > > +++ b/transport-pci.tex
> > > @@ -325,6 +325,10 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
> > >           /* About the administration virtqueue. */
> > >           le16 admin_queue_index;         /* read-only for driver */
> > >           le16 admin_queue_num;         /* read-only for driver */
> > > +
> > > +	/* Virtqueue state */
> > > +        le16 queue_avail_state;         /* read-write */
> > > +        le16 queue_used_state;          /* read-write */
> > >   };
> > >   \end{lstlisting}
> > > @@ -428,6 +432,17 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
> > >   	The value 0 indicates no supported administration virtqueues.
> > >   	This field is valid only if VIRTIO_F_ADMIN_VQ has been
> > >   	negotiated.
> > > +
> > > +\item[\field{queue_avail_state}]
> > > +        This field is valid only if VIRTIO_F_QUEUE_STATE has been
> > > +        negotiated. The driver sets and gets the available state of
> > > +        the virtqueue here (see \ref{sec:Virtqueues / Virtqueue State}).
> > > +
> > > +\item[\field{queue_used_state}]
> > > +        This field is valid only if VIRTIO_F_QUEUE_STATE has been
> > > +        negotiated. The driver sets and gets the used state of the
> > > +        virtqueue here (see \ref{sec:Virtqueues / Virtqueue State}).
> > > +
> > >   \end{description}
> > >   \devicenormative{\paragraph}{Common configuration structure layout}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout}
> > 
> > Two fields are pointless in the general case.  Fix this to at least
> > support out of order buffer use, then there's something to talk about.
> > I suspect we'll be back to yet another bespoke mailbox and a bitmap for
> > this.
> For split virtqueue, it has available ring, used ring and descriptor table,
> means the device can always tell which descriptor/buffer is in-flight
> or not processed even when out_of_order.

Unfortunately, I don't believe so. Hard to say exactly without a
specific algorithm you propose what the bug in it is. Describe an
algorithm I should be able to point the issues out to you.


> For packed virtqueue, because the descriptors may be overwritten, so when
> out_out_order, the descriptors behind last_avial_idx should be considered
> as in-flight and should be processed at the destination side.
> 
> Does this work for you?

Not without a lot more detail.


> > 
> > 
> > > @@ -488,6 +503,9 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
> > >   present either a value of 0 or a power of 2 in
> > >   \field{queue_size}.
> > > +If VIRTIO_F_QUEUE_STATE has not been negotiated, the device MUST ignore
> > > +any accesses to \field{queue_avail_state} and \field{queue_used_state}.
> > > +
> > >   If VIRTIO_F_ADMIN_VQ has been negotiated, the value
> > >   \field{admin_queue_index} MUST be equal to, or bigger than
> > >   \field{num_queues}; also, \field{admin_queue_num} MUST be
> > > -- 
> > > 2.35.3