Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: virtio-comment@lists.oasis-open.org, cohuck@redhat.com,
	virtio-dev@lists.oasis-open.org, jasowang@redhat.com,
	parav@nvidia.com, shahafs@nvidia.com, oren@nvidia.com,
	stefanha@redhat.com
Subject: Re: [PATCH v1 4/5] Add virtio Admin virtqueue
Date: Mon, 4 Apr 2022 12:13:41 -0400	[thread overview]
Message-ID: <20220404120950-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <5677b877-129a-d481-ea5d-7be6f0ccc66a@nvidia.com>

On Mon, Apr 04, 2022 at 06:49:19PM +0300, Max Gurtovoy wrote:
> 
> On 4/4/2022 4:02 PM, Michael S. Tsirkin wrote:
> > On Wed, Mar 02, 2022 at 05:56:07PM +0200, Max Gurtovoy wrote:
> > > In one of the many use cases a user wants to manipulate features and
> > > configuration of the virtio devices regardless of the device type
> > > (net/block/console). Some of this configuration is generic enough. i.e
> > > Number of MSI-X vectors of a virtio PCI VF device. There is a need to do
> > > such features query and manipulation by its parent PCI PF. For that the
> > > Admin Command Set introduced. The Admin virtqueue will be the first
> > > management interface to issue Admin commands.
> > > 
> > > Currently virtio specification defines control virtqueue to manipulate
> > > features and configuration of the device it operates on. However,
> > > control virtqueue commands are device type specific, which makes it very
> > > difficult to extend for device agnostic commands.
> > > 
> > > To support this requirement in elegant way, this patch introduces a new
> > > admin virtqueue interface.
> > > 
> > > Manipulate features via admin virtqueue is asynchronous, scalable, easy
> > > to extend and doesn't require additional and expensive on-die resources
> > > to be allocated for every new feature that will be added in the future.
> > > 
> > > Reviewed-by: Parav Pandit <parav@nvidia.com>
> > > Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> > > ---
> > >   admin.tex       | 17 +++++++++++++++++
> > >   conformance.tex |  1 +
> > >   content.tex     |  6 ++++--
> > >   3 files changed, 22 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/admin.tex b/admin.tex
> > > index 9a8969b..ed9f6bd 100644
> > > --- a/admin.tex
> > > +++ b/admin.tex
> > > @@ -158,3 +158,20 @@ \subsection{VIRTIO ADMIN DEVICE INFO command}\label{sec:Basic Facilities of a Vi
> > >   specification and can't be equal to zero. If bit 0 is not set, the driver will ignore \field{vf_number}.}
> > >   \end{note}
> > > +\section{Admin Virtqueues}\label{sec:Basic Facilities of a Virtio Device / Admin Virtqueues}
> > > +
> > > +An admin virtqueue is a management interface of a device that can be used to send administrative
> > > +commands to manipulate various features of the device and/or to manipulate
> > > +various features, if possible, of another device within the same virtio subsystem
> > > +(see \ref{sec:Introduction / Definitions / virtio subsystem}).
> > > +
> > > +An admin virtqueue exists for a certain device if VIRTIO_F_ADMIN_VQ is
> > > +negotiated. The index of the admin virtqueue is exposed by the device in a
> > > +transport specific manner.
> > > +
> > > +If VIRTIO_F_ADMIN_VQ has been negotiated, the driver will use the admin virtqueue to send all admin commands.
> > > +
> > Add links please, and explain how do commands map to VQ buffers.
> 
> I added a link to the definitions section and I'll replace it with the new
> proposed terminology chapter.

That explains what a subsystem is.

> What other links should be added ?

A link to where it's explained how do admin commands look.

> > E.g. I guess device readable an output buffer and device writeable an input
> > buffer...
> 
> The buffers transfer from/to device/driver are using existing mechanism.
> Nothing new here.
> 
> It will just repeat existing chapters.

There could be some repetition but it's necessary to make things
explicit.  Look at e.g. 
subsection{Device Operation}\label{sec:Device Types / Block Device / Device Operation}
as a lightweight example for how to explain it.




> > 
> > > +\devicenormative{\subsection}{Admin Virtqueues}{Basic Facilities of a Virtio Device / Admin Virtqueues}
> > > +A device that advertises VIRTIO_F_ADMIN_VQ capability MUST support all the mandatory admin commands.
> > > +
> > > +A device that advertises VIRTIO_F_ADMIN_VQ capability MAY support one or more optional admin commands.
> > > diff --git a/conformance.tex b/conformance.tex
> > > index 42f8537..129831c 100644
> > > --- a/conformance.tex
> > > +++ b/conformance.tex
> > > @@ -341,6 +341,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > >   \item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / Available Buffer Notification Suppression}
> > >   \item \ref{devicenormative:Basic Facilities of a Virtio Device / Shared Memory Regions}
> > >   \item \ref{devicenormative:Reserved Feature Bits}
> > > +\item \ref{devicenormative:Basic Facilities of a Virtio Device / Admin Virtqueues}
> > >   \end{itemize}
> > >   \conformance{\subsection}{PCI Device Conformance}\label{sec:Conformance / Device Conformance / PCI Device Conformance}
> > > diff --git a/content.tex b/content.tex
> > > index 2e1df84..163cb34 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -99,10 +99,10 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B
> > >   \begin{description}
> > >   \item[0 to 23, and 50 to 127] Feature bits for the specific device type
> > > -\item[24 to 40] Feature bits reserved for extensions to the queue and
> > > +\item[24 to 41] Feature bits reserved for extensions to the queue and
> > >     feature negotiation mechanisms
> > > -\item[41 to 49, and 128 and above] Feature bits reserved for future extensions.
> > > +\item[42 to 49, and 128 and above] Feature bits reserved for future extensions.
> > >   \end{description}
> > >   \begin{note}
> > > @@ -6849,6 +6849,8 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> > >     that the driver can reset a queue individually.
> > >     See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}.
> > > +  \item[VIRTIO_F_ADMIN_VQ (41)] This feature indicates that an administration virtqueue is supported.
> > > +
> > >   \end{description}
> > >   \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
> > > -- 
> > > 2.21.0


  reply	other threads:[~2022-04-04 16:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02 15:56 [PATCH v1 0/5] Introduce virtio subsystem and Admin virtqueue Max Gurtovoy
2022-03-02 15:56 ` [PATCH v1 1/5] virtio: Introduce virtio subsystem Max Gurtovoy
2022-04-04 12:03   ` [virtio-dev] " Michael S. Tsirkin
2022-04-04 15:06     ` [virtio-comment] " Max Gurtovoy
2022-03-02 15:56 ` [virtio-comment] [PATCH v1 2/5] Introduce Admin Command Set Max Gurtovoy
2022-04-04 12:50   ` Michael S. Tsirkin
2022-04-04 15:35     ` Max Gurtovoy
2022-04-04 16:26       ` Michael S. Tsirkin
2022-04-05 10:58         ` [virtio-comment] " Max Gurtovoy
2022-04-05 12:28           ` [virtio-dev] " Michael S. Tsirkin
2022-04-06 17:03             ` [virtio-comment] " Max Gurtovoy
2022-03-02 15:56 ` [PATCH v1 3/5] Introduce DEVICE INFO Admin command Max Gurtovoy
2022-04-04 12:57   ` Michael S. Tsirkin
2022-04-04 15:44     ` Max Gurtovoy
2022-04-04 16:09       ` Michael S. Tsirkin
2022-04-05 11:27         ` [virtio-comment] " Max Gurtovoy
2022-04-05 12:20           ` Michael S. Tsirkin
2022-04-06 17:17             ` [virtio-comment] " Max Gurtovoy
2022-03-02 15:56 ` [PATCH v1 4/5] Add virtio Admin virtqueue Max Gurtovoy
2022-04-04 13:02   ` Michael S. Tsirkin
2022-04-04 15:49     ` Max Gurtovoy
2022-04-04 16:13       ` Michael S. Tsirkin [this message]
2022-04-05 11:13         ` [virtio-comment] " Max Gurtovoy
2022-04-05 12:32           ` [virtio-dev] " Michael S. Tsirkin
2022-03-02 15:56 ` [PATCH v1 5/5] Add miscellaneous configuration structure for PCI Max Gurtovoy
2022-04-04 13:04   ` Michael S. Tsirkin
2022-04-04 15:52     ` Max Gurtovoy
2022-04-04 16:16       ` Michael S. Tsirkin
2022-04-05 11:20         ` [virtio-comment] " Max Gurtovoy
2022-04-05 12:12           ` Michael S. Tsirkin
2022-03-09  7:42 ` [PATCH v1 0/5] Introduce virtio subsystem and Admin virtqueue Michael S. Tsirkin
2022-03-10 10:38   ` Max Gurtovoy
2022-03-10 12:49     ` Michael S. Tsirkin
2022-03-10 13:08       ` Max Gurtovoy
2022-03-20 21:41         ` [virtio-comment] " Michael S. Tsirkin
2022-03-27 15:40           ` Max Gurtovoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220404120950-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=oren@nvidia.com \
    --cc=parav@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox