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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.