From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: virtio-comment@lists.oasis-open.org,
virtio-dev@lists.oasis-open.org, cohuck@redhat.com,
sgarzare@redhat.com, stefanha@redhat.com, nrupal.jani@intel.com,
Piotr.Uminski@intel.com, hang.yuan@intel.com,
virtio@lists.oasis-open.org,
Zhu Lingshan <lingshan.zhu@intel.com>,
pasic@linux.ibm.com, Shahaf Shuler <shahafs@nvidia.com>,
Parav Pandit <parav@nvidia.com>,
Max Gurtovoy <mgurtovoy@nvidia.com>
Subject: Re: [PATCH v9 03/10] admin: introduce group administration commands
Date: Thu, 24 Nov 2022 03:03:00 -0500 [thread overview]
Message-ID: <20221124025909-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEuUYmx9MO6Yui+6orLU99FAS6kgNqf9Gcv_nNoGtJL5nQ@mail.gmail.com>
On Thu, Nov 24, 2022 at 03:42:18PM +0800, Jason Wang wrote:
> On Thu, Nov 24, 2022 at 3:12 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Nov 24, 2022 at 01:52:41PM +0800, Jason Wang wrote:
> > > On Thu, Nov 24, 2022 at 5:08 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > This introduces a general structure for group administration commands,
> > > > used to control device groups through their owner.
> > > >
> > > > Following patches will introduce specific commands and an interface for
> > > > submitting these commands to the owner.
> > > >
> > > > Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > > admin.tex | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 98 insertions(+)
> > > >
> > > > diff --git a/admin.tex b/admin.tex
> > > > index 6ebdd05..1dca136 100644
> > > > --- a/admin.tex
> > > > +++ b/admin.tex
> > > > @@ -42,4 +42,102 @@ \section{Device groups}\label{sec:Basic Facilities of a Virtio Device / Device g
> > > > PCI transport (see \ref{sec:Virtio Transport Options / Virtio Over PCI Bus}).
> > > > \end{description}
> > > >
> > > > +\subsection{Group administration commands}\label{sec:Basic Facilities of a Virtio Device / Device groups / Group administration commands}
> > > >
> > > > +Group administration commands can be issued through an owner
> > > > +device to control member devices of a group. This mechanism can
> > > > +be used, for example, to configure a member device before it is
> > > > +initialized by its driver.
> > >
> > > This excludes any possible runtime configuration, is this intended?
> >
> > No idea - what kind of runtime configuration are you talking about?
> > This explicitly says "to configure a member device" and that's
> > certainly at runtime.
>
> Not sure, but if we say something like we, it means we need a group of
> commands to support runtime stuff in the future?
we'll need commands to provision members - is this what you
mean? for sure.
> >
> >
> > >
> > > > +
> > > > +All the group administration commands are of the following form:
> > > > +
> > > > +\begin{lstlisting}
> > > > +struct virtio_admin_cmd {
> > > > + /* Device-readable part */
> > > > + le16 opcode;
> > > > + /*
> > > > + * 1 - SR-IOV
> > > > + * 2 - 65535 reserved
> > > > + */
> > > > + le16 group_type;
> > > > + /* unused, reserved for future extensions */
> > > > + u8 reserved1[12];
> > > > + le64 group_member_id;
> > > > + u8 command_specific_data[];
> > > > +
> > > > + /* Device-writable part */
> > > > + le16 status;
> > > > + le16 status_qualifier;
> > > > + /* unused, reserved for future extensions */
> > > > + u8 reserved2[4];
> > > > + u8 command_specific_result[];
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +For all commands, \field{opcode}, \field{group_type} and if
> > > > +necessary \field{group_member_id} and \field{command_specific_data} are
> > > > +set by the driver, and the owner device sets \field{status} and if
> > > > +needed \field{status_qualifier} and
> > > > +\field{command_specific_result}.
> > > > +
> > > > +As a rule, any unused device-readable fields are set to zero by the driver
> > > > +and ignored by the device. Any unused device-writeable fields are set to zero
> > > > +by the device and ignored by the driver.
> > > > +
> > > > +\field{opcode} specifies the command. The valid
> > > > +values for \field{opcode} can be found in the following table:
> > > > +
> > > > +\begin{tabular}{|l|l|}
> > > > +\hline
> > > > +opcode & Name & Command Description \\
> > > > +\hline \hline
> > > > +0x0000 - 0x7FFF & - & Group administration commands \\
> > > > +\hline
> > > > +0x8000 - 0xFFFF & - & Reserved \\
> > > > +\hline
> > > > +\end{tabular}
> > > > +
> > > > +The \field{group_type} specifies the group type identifier.
> > >
> > > So this means there's no way for having a group specific adminq? E.g
> > > one queue for SR-IOV and another for SIOV.
> > >
> > > > +The \field{group_member_id} specifies the member identifier within the group.
> > > > +See section \ref{sec:Introduction / Terminology / Device group}
> > > > +for the definition of the group type identifier and group member
> > > > +identifier.
> > > > +
> > > > +The following table describes possible \field{status} values;
> > > > +to simplify common implementations, they are intentionally
> > > > +matching common Linux names and error numbers:
> > >
> > > I may miss something but I don't see how it matches Linux error numbers.
> >
> >
> > include/uapi/asm-generic/errno-base.h:#define EINVAL 22 /* Invalid argument */
>
> Ok, only this one was matched but any advantages of menting the
> matching? I believe not all the error numbers are meaningful for a
> device interface (e.g EINTR).
>
> Thanks
Makes it easier for driver to decide on an error to
report to userspace. If we don't use all error codes
that's fine.
> >
> >
> > > Thanks
> > >
> > > > +
> > > > +\begin{tabular}{|l|l|l|}
> > > > +\hline
> > > > +Status (decimal) & Name & Description \\
> > > > +\hline \hline
> > > > +00 & VIRTIO_ADMIN_STATUS_OK & successful completion \\
> > > > +\hline
> > > > +22 & VIRTIO_ADMIN_STATUS_EINVAL & invalid command \\
> > > > +\hline
> > > > +other & - & group administration command error \\
> > > > +\hline
> > > > +\end{tabular}
> > > > +
> > > > +When \field{status} is VIRTIO_ADMIN_STATUS_OK, \field{status_qialifier}
> > > > +is reserved and set to zero by the device.
> > > > +
> > > > +When \field{status} is VIRTIO_ADMIN_STATUS_EINVAL,
> > > > +the following table describes possible \field{status_qialifier} values:
> > > > +\begin{tabular}{|l|l|l|}
> > > > +\hline
> > > > +Status & Name & Description \\
> > > > +\hline \hline
> > > > +0x00 & VIRTIO_ADMIN_STATUS_Q_INVALID_COMMAND & command error: no additional information \\
> > > > +\hline
> > > > +0x01 & VIRTIO_ADMIN_STATUS_Q_INVALID_OPCODE & unsupported or invalid \field{opcode} \\
> > > > +\hline
> > > > +0x02 & VIRTIO_ADMIN_STATUS_Q_INVALID_FIELD & unsupported or invalid field within \field{command_specific_data} \\
> > > > +\hline
> > > > +0x03 & VIRTIO_ADMIN_STATUS_Q_INVALID_GROUP & unsupported or invalid \field{group_type} \\
> > > > +\hline
> > > > +0x04 & VIRTIO_ADMIN_STATUS_Q_INVALID_MEM & unsupported or invalid \field{group_member_id} \\
> > > > +\hline
> > > > +0x05-0xFFFF & - & reserved for future use \\
> > > > +\hline
> > > > +\end{tabular}
> > > > --
> > > > MST
> > > >
> >
next prev parent reply other threads:[~2022-11-24 8:03 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 21:07 [PATCH v9 00/10] Introduce device group and device management Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 01/10] virtio: document forward compatibility guarantees Michael S. Tsirkin
2022-11-24 4:33 ` Jason Wang
2022-11-24 6:59 ` Michael S. Tsirkin
2022-11-24 7:34 ` Jason Wang
2022-11-24 8:15 ` Michael S. Tsirkin
2022-11-24 12:05 ` [virtio-dev] " Cornelia Huck
2022-11-25 3:17 ` Jason Wang
2022-11-25 10:37 ` [virtio-dev] " Cornelia Huck
2022-11-28 6:14 ` Jason Wang
2022-11-23 21:08 ` [PATCH v9 02/10] admin: introduce device group and related concepts Michael S. Tsirkin
2022-11-24 5:41 ` Jason Wang
2022-11-24 7:08 ` Michael S. Tsirkin
2022-11-24 7:37 ` [virtio-dev] " Jason Wang
2022-11-24 8:18 ` Michael S. Tsirkin
2022-11-24 12:12 ` Cornelia Huck
2022-11-25 3:23 ` Jason Wang
2022-11-25 10:58 ` [virtio] " Cornelia Huck
2022-11-25 12:08 ` Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 03/10] admin: introduce group administration commands Michael S. Tsirkin
2022-11-24 5:52 ` [virtio-dev] " Jason Wang
2022-11-24 7:12 ` Michael S. Tsirkin
2022-11-24 7:42 ` Jason Wang
2022-11-24 8:03 ` Michael S. Tsirkin [this message]
2022-11-25 3:24 ` [virtio-comment] " Jason Wang
2022-11-24 12:21 ` [virtio-dev] " Cornelia Huck
2022-11-25 3:54 ` Jason Wang
2022-11-28 13:14 ` [virtio-comment] " Zhu Lingshan
2022-11-23 21:08 ` [PATCH v9 04/10] admin: introduce virtio admin virtqueues Michael S. Tsirkin
2022-11-28 13:12 ` [virtio-comment] " Zhu Lingshan
2022-11-23 21:08 ` [PATCH v9 05/10] pci: add admin vq registers to virtio over pci Michael S. Tsirkin
2022-11-24 6:00 ` Jason Wang
2022-11-24 7:14 ` Michael S. Tsirkin
2022-11-24 7:46 ` Jason Wang
2022-11-24 8:09 ` Michael S. Tsirkin
2022-11-25 3:27 ` Jason Wang
2022-11-23 21:08 ` [PATCH v9 06/10] mmio: document ADMIN_VQ as reserved Michael S. Tsirkin
2022-11-24 6:03 ` Jason Wang
2022-11-24 7:45 ` Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 07/10] ccw: " Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 08/10] admin: command list discovery Michael S. Tsirkin
2022-11-24 6:40 ` Jason Wang
2022-11-24 8:30 ` Michael S. Tsirkin
2022-11-25 3:38 ` [virtio-comment] " Jason Wang
2022-11-25 11:43 ` Michael S. Tsirkin
2022-11-28 4:34 ` Jason Wang
2022-11-28 7:42 ` Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 09/10] admin: conformance clauses Michael S. Tsirkin
2022-11-24 6:51 ` Jason Wang
2022-11-24 8:36 ` Michael S. Tsirkin
2022-11-25 3:50 ` Jason Wang
2022-11-25 11:42 ` [virtio] " Cornelia Huck
2022-11-25 11:56 ` Michael S. Tsirkin
2022-11-25 12:10 ` [virtio] " Cornelia Huck
2022-11-25 11:47 ` Michael S. Tsirkin
2022-11-28 4:32 ` Jason Wang
2022-11-28 7:39 ` Michael S. Tsirkin
2022-11-24 12:28 ` [virtio] " Cornelia Huck
2022-11-25 3:38 ` Jason Wang
2022-11-23 21:08 ` [PATCH RFC v9 10/10] ccw: document more reserved features Michael S. Tsirkin
2022-11-24 6:53 ` Jason Wang
2022-11-24 8:31 ` Michael S. Tsirkin
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=20221124025909-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Piotr.Uminski@intel.com \
--cc=cohuck@redhat.com \
--cc=hang.yuan@intel.com \
--cc=jasowang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=mgurtovoy@nvidia.com \
--cc=nrupal.jani@intel.com \
--cc=parav@nvidia.com \
--cc=pasic@linux.ibm.com \
--cc=sgarzare@redhat.com \
--cc=shahafs@nvidia.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtio@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.