From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: virtio-comment@lists.linux.dev, cohuck@redhat.com, shahafs@nvidia.com
Subject: Re: [PATCH] admin: Enable driver to send admin commands before DRIVER_OK
Date: Tue, 10 Sep 2024 14:31:56 -0400 [thread overview]
Message-ID: <20240910142850-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20240910170723.44537-1-parav@nvidia.com>
On Tue, Sep 10, 2024 at 08:07:23PM +0300, Parav Pandit wrote:
> Currently the driver can operate administration commands using
> administration virtqueues. Administration virtqueues must be
> enabled before it reached DRIVER_OK stage similar to all other
> queues. This is a limiting factor.
>
> Many of the device functionalties needs to be discovered and
> configured early enough before the driver reaches the
> DRIVER_OK stage. Some examples are:
>
> a. driver wants to dynamically create the virtqueues of virtio-net
> device with more parameters, for example header data split,
> multiple physical addresses.
> Here, the driver needs to tell PCI device early enough that it no
> longer uses queue_* registers for non admin queues.
>
> b. driver wants to discover these features and related attributes
> early enough so it has chance to decide to proceed via admin
> cmd interface or proceed to DRIVER_OK and follow the current flow.
>
> To overcome these limitations, introduce a feature bit that enables
> the driver to send capabilities related admin commands before DRIVER_OK
> via the available interface such as administration virtqueue.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
We were there in 1.0 and it's messy. And next thing you do, you will
want it before features ok, and we will keep piling up hacks. I think
that if we want to do admin commands before VQs are active, we should
just add a capability with registers for that. People wanted that
anyway.
> ---
> admin.tex | 16 ++++++++++++++++
> content.tex | 13 ++++++++++++-
> transport-pci.tex | 6 ++++++
> 3 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/admin.tex b/admin.tex
> index 39fc072..95054ed 100644
> --- a/admin.tex
> +++ b/admin.tex
> @@ -334,6 +334,11 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
> supporting multiple group types, the list of supported commands
> might differ between different group types.
>
> +When the driver has negotiated the feature VIRTIO_F_EARLY_CAP_ADMIN_CMD, the
> +driver can use administration commands VIRTIO_ADMIN_CMD_LIST_QUERY,
> +VIRTIO_ADMIN_CMD_LIST_USE and commands related to device and driver capabilities
> +listed in \ref[sec:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Device and driver capabilities]{device and driver capabilities} for the self-group type before the driver indicates DRIVER_OK status to the device.
> +
> \input{admin-cmds-legacy-interface.tex}
> \input{admin-cmds-capabilities.tex}
> \input{admin-cmds-resource-objects.tex}
> @@ -608,6 +613,14 @@ \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Devic
> or VIRTIO_ADMIN_STATUS_ENOMEM, then the command MUST NOT
> have any side effects, making it safe to retry.
>
> +If VIRTIO_F_EARLY_CAP_ADMIN_CMD feature is negotiated, the device MUST process
> +administration commands related to device and driver capabilities before the
> +driver indicates DRIVER_OK to the device.
> +
> +If VIRTIO_F_ADMIN_VQ and VIRTIO_F_EARLY_CAP_ADMIN_CMD features are negotiated,
> +the device MUST be able to generate notifications related to the administration
> +virtqueue before the driver indicates DRIVER_OK to the device.
> +
> \drivernormative{\subsection}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
>
> The driver MAY supply device-readable or device-writeable parts
> @@ -641,3 +654,6 @@ \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Devic
>
> The driver SHOULD retry a command that completed with
> \field{status} VIRTIO_ADMIN_STATUS_EAGAIN.
> +
> +When the VIRTIO_F_EARLY_ADMIN_CMD feature is negotiated, the driver MAY send commands
> +only to the first administration queue defined by the specific transport.
> diff --git a/content.tex b/content.tex
> index c32c218..12f9224 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -540,6 +540,8 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
> device, optional per-bus setup, reading and possibly writing the
> device's virtio configuration space, and population of virtqueues.
>
> +\item\label{itm:General Initialization And Device Operation / Device Initialization / Capabilities Access} Optionally get device capabilities and set driver capabilities if VIRTIO_F_EARLY_CAP_ADMIN_CMD is negotiated.
> +
> \item\label{itm:General Initialization And Device Operation / Device Initialization / Set DRIVER-OK} Set the DRIVER_OK status bit. At this point the device is
> ``live''.
> \end{enumerate}
> @@ -550,7 +552,9 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
> driver MUST NOT continue initialization in that case.
>
> The driver MUST NOT send any buffer available notifications to
> -the device before setting DRIVER_OK.
> +the device before setting DRIVER_OK; however, the driver MAY send
> +buffer available notifications before setting DRIVER_OK if
> +VIRTIO_F_EARLY_CAP_ADMIN_CMD is negotiated.
>
> \subsection{Legacy Interface: Device Initialization}\label{sec:General Initialization And Device Operation / Device Initialization / Legacy Interface: Device Initialization}
> Legacy devices did not support the FEATURES_OK status bit, and thus did
> @@ -879,6 +883,13 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> \ref{devicenormative:Basic Facilities of a Virtio Device / Feature Bits} for
> handling features reserved for future use.
>
> + \item[VIRTIO_F_EARLY_CAP_ADMIN_CMD(42)] This feature indicates that the device
> + exposes an administration command interface which is accessible to the driver
> + before the driver indicates DRIVER_OK device status. When this feature is
> + negotiated, once the the administration commands interface is configured, it can be
> + used by the driver to issue administration commands related to device and driver
> + capabilities.
> +
> \end{description}
>
> \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
> diff --git a/transport-pci.tex b/transport-pci.tex
> index 95b08b8..a612b34 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -495,6 +495,12 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
> to ensure that indices of valid admin queues fit into
> a 16 bit range beyond all other virtqueues.
>
> +If VIRTIO_F_ADMIN_VQ and VIRTIO_F_EARLY_ADMIN_CMD has been negotiated,
> +the device MUST support administration commands through the
> +administration virtqueue identified by the \field{admin_queue_index}
> +after the administration virtqueue is enabled and
> +before the driver sets DRIVER_OK to the \field{device_status}.
> +
> \drivernormative{\paragraph}{Common configuration structure layout}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout}
>
> The driver MUST NOT write to \field{device_feature}, \field{num_queues},
> --
> 2.34.1
next prev parent reply other threads:[~2024-09-10 18:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 17:07 [PATCH] admin: Enable driver to send admin commands before DRIVER_OK Parav Pandit
2024-09-10 18:31 ` Michael S. Tsirkin [this message]
2024-09-10 19:01 ` Parav Pandit
2024-09-10 20:35 ` Michael S. Tsirkin
2024-09-11 3:37 ` Parav Pandit
2024-09-11 3:59 ` Zhu Lingshan
2024-09-11 4:03 ` Parav Pandit
2024-09-11 4:38 ` Jason Wang
2024-09-11 4:42 ` Parav Pandit
2024-09-11 4:42 ` Zhu Lingshan
2024-09-11 4:45 ` Parav Pandit
2024-09-11 5:04 ` Jason Wang
2024-09-11 5:06 ` Parav Pandit
2024-09-11 5:06 ` Jason Wang
2024-09-13 19:03 ` Michael S. Tsirkin
2024-09-14 5:37 ` Zhu Lingshan
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=20240910142850-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=parav@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.linux.dev \
/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