From: "Michael S. Tsirkin" <mst@redhat.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: jasowang@redhat.com, virtio-comment@lists.oasis-open.org,
cohuck@redhat.com, virtio-dev@lists.oasis-open.org,
oren@nvidia.com, parav@nvidia.com, shahafs@nvidia.com,
aadam@redhat.com, virtio@lists.oasis-open.org
Subject: Re: [PATCH v5 3/7] Introduce new destination type for admin commands
Date: Sun, 15 May 2022 11:09:10 -0400 [thread overview]
Message-ID: <20220515110536-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220426225824.5918-4-mgurtovoy@nvidia.com>
On Wed, Apr 27, 2022 at 01:58:20AM +0300, Max Gurtovoy wrote:
> Introduce a new mechanism to issue commands with dst_type field that is
> not "self". With the new mechanism, driver can set dst_type to 1
> and use the vdev_id common field to describe the designated vdev_id.
>
> This mechanism is useful for device groups with multiple devices
> with various different capabilities. For example, a type 1 device group
> that contains a PCI PF and its VF. For this group, a clever system
> administrator can use admin commands to manipulate the PF/VF resources.
>
> Reviewed-by: Parav Pandit <parav@nvidia.com>
> Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> ---
> admin.tex | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/admin.tex b/admin.tex
> index 6725daa..f816c3b 100644
> --- a/admin.tex
> +++ b/admin.tex
> @@ -11,11 +11,13 @@ \section{Administration command set}\label{sec:Basic Facilities of a Virtio Devi
> le16 command;
> /*
> * 0 - self
> - * 1 - 65535 are reserved
> + * 1 - other virtio device (identified by vdev_id) in the same device group
> + * 2 - 65535 are reserved
> */
> le16 dst_type;
> + le64 vdev_id;
Alignment problems. Proposal:
vdev_id
dst_type
command
> /* reserved for common cmd fields */
> - u8 reserved[20];
> + u8 reserved[12];
> u8 command_specific_data[];
>
> /* Device-writable part */
> @@ -39,9 +41,11 @@ \section{Administration command set}\label{sec:Basic Facilities of a Virtio Devi
> \hline
> 03h & VIRTIO_ADMIN_STATUS_INVALID_FIELD & invalid field was set \\
> \hline
> +04h & VIRTIO_ADMIN_STATUS_INVALID_VDEV_ID & invalid vdev_id was set \\
> +\hline
> \end{tabular}
>
> -The \field{command}, \field{dst_type} and \field{command_specific_data} are
> +The \field{command}, \field{dst_type}, \field{vdev_id} and \field{command_specific_data} are
> set by the driver, and the device sets the \field{status}, the
> \field{command_specific_error} and the \field{command_specific_result},
> if needed.
> @@ -50,9 +54,15 @@ \section{Administration command set}\label{sec:Basic Facilities of a Virtio Devi
>
> The mandatory fields to be set by the driver, for all admin commands, are \field{command} and \field{dst_type}.
>
> +The optional unused fields to be zeroed by the driver.
> +
> The \field{command} defines the opcode for the command. The value for each command can be found in each command section.
>
> -The \field{dst_type} defines the designated virtio device for the command. This value should be set to 0 (self).
> +The \field{dst_type} defines the designated virtio device for the command. This value can be set to 0 (self) or 1 (other virtio device in the same device
> +group) by the driver. Not all the commands allow setting \field{dst_type} to 1. Refer to each command description explicitly to check whether this operation is allowed.
> +If \field{dst_type} is set to 0 by the driver, the \field{vdev_id} isn't valid, should be zeroed by the driver and should be ignored by the device.
> +If \field{dst_type} is set to 1 by the driver, the \field{vdev_id} is valid and used to describe the vdev_id of the designated virtio device (see section
> +\ref{sec:Introduction / Terminology / Device group} for vdev_id numbering for type 1 device groups).
>
> The \field{command_specific_error} should be inspected by the driver only if \field{status} is set to
> VIRTIO_ADMIN_STATUS_CS_ERR by the device. In this case, the content of \field{command_specific_error}
teminology is a bit inconsistent. would dst_id be better? it goes
together with dst_type after all.
> --
> 2.21.0
next prev parent reply other threads:[~2022-05-15 15:09 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 22:58 [PATCH v5 0/7] Introduce device group and device management Max Gurtovoy
2022-04-26 22:58 ` [virtio-comment] [PATCH v5 1/7] Introduce device group Max Gurtovoy
2022-05-15 15:25 ` Michael S. Tsirkin
2022-05-18 13:14 ` [virtio-comment] " Max Gurtovoy
2022-05-18 13:32 ` Cornelia Huck
2022-06-01 13:43 ` Max Gurtovoy
2022-06-02 2:21 ` Jason Wang
2022-06-02 6:59 ` Michael S. Tsirkin
2022-06-27 21:52 ` Max Gurtovoy
2022-06-28 18:54 ` Michael S. Tsirkin
2022-07-06 11:25 ` Max Gurtovoy
2022-07-06 11:42 ` Michael S. Tsirkin
2022-07-06 12:01 ` Max Gurtovoy
2022-07-06 12:23 ` Michael S. Tsirkin
2022-07-06 15:18 ` Max Gurtovoy
2022-04-26 22:58 ` [PATCH v5 2/7] Introduce admin command set Max Gurtovoy
2022-05-15 15:23 ` Michael S. Tsirkin
2022-05-16 21:08 ` [virtio-comment] " Parav Pandit
2022-05-17 10:08 ` [virtio-dev] " Cornelia Huck
2022-05-18 13:42 ` Max Gurtovoy
2022-05-17 11:48 ` Michael S. Tsirkin
2022-05-18 14:09 ` Max Gurtovoy
2022-05-18 14:42 ` [virtio] " Cornelia Huck
2022-05-18 14:48 ` Max Gurtovoy
2022-05-31 20:39 ` Parav Pandit
2022-06-20 9:23 ` Michael S. Tsirkin
2022-06-20 9:49 ` Michael S. Tsirkin
2022-06-20 9:59 ` Michael S. Tsirkin
2022-06-20 11:06 ` Parav Pandit
2022-06-20 16:46 ` Michael S. Tsirkin
2022-06-20 16:54 ` Max Gurtovoy
2022-06-20 17:04 ` Michael S. Tsirkin
2022-06-20 17:19 ` Parav Pandit
2022-06-20 20:53 ` Michael S. Tsirkin
2022-06-20 23:54 ` Parav Pandit
2022-06-20 17:16 ` Parav Pandit
2022-06-23 1:26 ` Jason Wang
2022-06-23 2:07 ` Parav Pandit
2022-06-23 2:41 ` Jason Wang
2022-06-23 2:57 ` Parav Pandit
2022-06-23 3:34 ` Jason Wang
2022-06-28 14:24 ` Michael S. Tsirkin
2022-06-29 8:43 ` Jason Wang
2022-06-29 9:02 ` Michael S. Tsirkin
2022-06-30 1:53 ` Jason Wang
2022-05-18 13:39 ` [virtio-comment] " Max Gurtovoy
2022-05-18 13:50 ` [virtio] " Cornelia Huck
2022-05-18 14:16 ` Max Gurtovoy
2022-06-20 22:26 ` Michael S. Tsirkin
2022-06-20 21:08 ` Michael S. Tsirkin
2022-04-26 22:58 ` [PATCH v5 3/7] Introduce new destination type for admin commands Max Gurtovoy
2022-05-15 15:01 ` Michael S. Tsirkin
2022-05-18 14:27 ` [virtio-comment] " Max Gurtovoy
2022-05-15 15:09 ` Michael S. Tsirkin [this message]
2022-05-16 21:21 ` Parav Pandit
2022-05-16 23:33 ` Michael S. Tsirkin
2022-05-18 14:36 ` Max Gurtovoy
2022-05-18 14:34 ` Max Gurtovoy
2022-05-18 23:55 ` Michael S. Tsirkin
2022-04-26 22:58 ` [PATCH v5 4/7] Introduce virtio admin virtqueue Max Gurtovoy
2022-05-15 14:59 ` Michael S. Tsirkin
2022-05-18 14:37 ` Max Gurtovoy
2022-05-18 23:56 ` Michael S. Tsirkin
2022-04-26 22:58 ` [PATCH v5 5/7] Add miscellaneous configuration structure for PCI Max Gurtovoy
2022-05-15 14:49 ` Michael S. Tsirkin
2022-06-01 14:46 ` Max Gurtovoy
2022-05-15 14:57 ` Michael S. Tsirkin
2022-05-17 10:12 ` [virtio] " Cornelia Huck
2022-05-18 14:42 ` Max Gurtovoy
2022-05-18 23:58 ` Michael S. Tsirkin
2022-04-26 22:58 ` [PATCH v5 6/7] Introduce MGMT admin commands Max Gurtovoy
2022-05-15 14:37 ` Michael S. Tsirkin
2022-05-16 21:47 ` Parav Pandit
2022-05-17 12:31 ` [virtio-comment] " Michael S. Tsirkin
2022-05-18 15:14 ` Max Gurtovoy
2022-05-17 2:28 ` Jason Wang
2022-05-18 15:27 ` Max Gurtovoy
2022-05-18 16:41 ` Michael S. Tsirkin
2022-05-18 23:10 ` Max Gurtovoy
2022-05-18 15:03 ` Max Gurtovoy
2022-06-20 9:45 ` Michael S. Tsirkin
2022-04-26 22:58 ` [PATCH v5 7/7] RFC: add initial support for configuring feature bits Max Gurtovoy
2022-05-15 14:38 ` Michael S. Tsirkin
2022-05-18 15:31 ` Max Gurtovoy
2022-05-18 16:34 ` Michael S. Tsirkin
2022-05-18 23:18 ` Max Gurtovoy
2022-05-15 15:27 ` [PATCH v5 0/7] Introduce device group and device management Michael S. Tsirkin
2022-05-18 15:32 ` Max Gurtovoy
2022-07-05 13:56 ` Michael S. Tsirkin
2022-07-05 15:11 ` [virtio-comment] " Parav Pandit
2022-07-06 2:54 ` [virtio-dev] " Jason Wang
2022-07-06 10:10 ` Michael S. Tsirkin
2022-07-06 10:46 ` [virtio-comment] " Parav Pandit
2022-07-06 11:00 ` Michael S. Tsirkin
2022-07-06 20:45 ` Parav Pandit
2022-07-24 21:09 ` Michael S. Tsirkin
2022-07-24 21:25 ` [virtio-comment] " Parav Pandit
2022-07-24 23:41 ` Michael S. Tsirkin
2022-07-25 2:53 ` [virtio-comment] " Parav Pandit
2022-07-25 7:44 ` Michael S. Tsirkin
2022-07-30 13:21 ` [virtio-comment] " Parav Pandit
2022-07-31 15:38 ` Michael S. Tsirkin
2022-08-02 17:40 ` Parav Pandit
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=20220515110536-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aadam@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox