All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
Cc: virtio-dev@lists.linux.dev, ebiggers@kernel.org,
	neeraj.soni@oss.qualcomm.com
Subject: Re: [PATCH v3 1/2] virtio-blk: Add the control virtqueue
Date: Thu, 17 Sep 2026 16:16:47 -0400	[thread overview]
Message-ID: <20260917201647.GB331587@fedora> (raw)
In-Reply-To: <20260913161628.368484-2-linlin.zhang@oss.qualcomm.com>

[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]

On Sun, Sep 13, 2026 at 09:16:14AM -0700, Linlin Zhang wrote:
> From: linlzhan <linlin.zhang@oss.qualcomm.com>
> 
> Add VIRTIO_BLK_F_CTRL_VQ to advertise control virtqueue support.
> 
> Define the control virtqueue location, driver queue discovery,
> and common control request buffer layout. This provides a
> standard framework for block-device control commands.
> 
> Signed-off-by: linlzhan <linlin.zhang@oss.qualcomm.com>
> ---
>  device-types/blk/description.tex | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> index 3b3a4e7..9bfdc4a 100644
> --- a/device-types/blk/description.tex
> +++ b/device-types/blk/description.tex
> @@ -13,11 +13,16 @@ \subsection{Virtqueues}\label{sec:Device Types / Block Device / Virtqueues}
>  \item[0] requestq1
>  \item[\ldots]
>  \item[N-1] requestqN
> +\item[N] controlq, if VIRTIO_BLK_F_CTRL_VQ is negotiated
>  \end{description}
>  
>   N=1 if VIRTIO_BLK_F_MQ is not negotiated, otherwise N is set by
>   \field{num_queues}.
>  
> +If VIRTIO_BLK_F_CTRL_VQ is negotiated, the control virtqueue is appended
> +after the request virtqueues. The control virtqueue is reserved for control
> +requests defined by this specification.
> +
>  \subsection{Feature bits}\label{sec:Device Types / Block Device / Feature bits}
>  
>  \begin{description}
> @@ -73,6 +78,8 @@ \subsection{Feature bits}\label{sec:Device Types / Block Device / Feature bits}
>      VIRTIO_BLK_REQ_FLAG_OUT_FUA flag in the \field{flags} bitfield of the
>      \field{virtio_blk_req} structure for VIRTIO_BLK_T_OUT requests.
>  
> +\item[VIRTIO_BLK_F_CTRL_VQ (22)] Device supports a control virtqueue.
> +
>  \end{description}
>  
>  \subsubsection{Legacy Interface: Feature bits}\label{sec:Device Types / Block Device / Feature bits / Legacy Interface: Feature bits}
> @@ -274,6 +281,9 @@ \subsection{Device Initialization}\label{sec:Device Types / Block Device / Devic
>  \item If the VIRTIO_BLK_F_MQ feature is negotiated, \field{num_queues} field
>      can be read to determine the number of queues.
>  
> +\item If the VIRTIO_BLK_F_CTRL_VQ feature is negotiated, the driver MUST
> +    identify the control virtqueue as queue N, after all request virtqueues.
> +
>  \item If the VIRTIO_BLK_F_SECURE_ERASE feature is negotiated,
>      \field{max_secure_erase_sectors} and \field{max_secure_erase_seg} can be read
>      to determine the maximum secure erase sectors and maximum number of
> @@ -327,6 +337,10 @@ \subsection{Device Initialization}\label{sec:Device Types / Block Device / Devic
>  The driver MUST NOT negotiate VIRTIO_BLK_F_REQ_FLAGS_OUT_FUA without
>  VIRTIO_BLK_F_REQ_FLAGS.
>  
> +If the VIRTIO_BLK_F_CTRL_VQ feature is negotiated, the driver MUST NOT submit
> +any request to the control virtqueue unless the request is defined by this
> +specification.
> +
>  \devicenormative{\subsubsection}{Device Initialization}{Device Types / Block Device / Device Initialization}
>  
>  Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it
> @@ -454,6 +468,11 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  };
>  \end{lstlisting}
>  
> +Control virtqueue requests consist of a type field in an output buffer,

Please move this paragraph to a separate subsection dedicate the control
virtqueue (like virtio-net's 5.1.9.5 Control Virtqueue in VIRTIO 1.4,
https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html#x1-2850009:~:text=5%2E1%2E9%2E5%20Control%20Virtqueue).

I recommend defining a separate struct virtio_blk_ctrl similar to
virtio-net's struct virtio_net_ctrl to illustrate the layout more
clearly than a paragraph of text could.

> +followed by an optional command-specific output buffer, an optional
> +command-specific input buffer, and a status byte in an input buffer. The
> +type field and status byte MUST each be in their own buffer.

Message framing is up to the driver and the device spec cannot dictate
specific framing:
https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html#x1-390004

> +
>  The type of the request is either a read (VIRTIO_BLK_T_IN), a write
>  (VIRTIO_BLK_T_OUT), a discard (VIRTIO_BLK_T_DISCARD), a write zeroes
>  (VIRTIO_BLK_T_WRITE_ZEROES), a flush (VIRTIO_BLK_T_FLUSH), a get device ID
> -- 
> 2.34.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2026-09-21 13:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13 16:16 [PATCH v3 0/2] virtio-blk: Add inline encryption support Linlin Zhang
2026-09-13 16:16 ` [PATCH v3 1/2] virtio-blk: Add the control virtqueue Linlin Zhang
2026-09-17 20:16   ` Stefan Hajnoczi [this message]
2026-09-22 11:10     ` Linlin Zhang
2026-09-13 16:16 ` [PATCH v3 2/2] virtio-blk: Add inline encryption support Linlin Zhang
2026-09-17 21:05   ` Stefan Hajnoczi
2026-09-24  9:32     ` Linlin Zhang
2026-09-17 21:08 ` [PATCH v3 0/2] " Stefan Hajnoczi
2026-09-22  4:29   ` Linlin Zhang
2026-09-22 13:14     ` Stefan Hajnoczi
2026-09-24  9:35       ` Linlin Zhang
2026-09-29 22:46         ` Max Gurtovoy
2026-10-08  9:17           ` Linlin Zhang
2026-10-08 10:15             ` Michael S. Tsirkin
2026-10-09 11:21               ` Linlin Zhang
2026-10-09 12:25                 ` Michael S. Tsirkin
2026-10-10 10:54                   ` Linlin Zhang
2026-10-12 14:51                     ` Linlin Zhang
2026-10-12 22:33                     ` Michael S. Tsirkin
2026-10-13 16:23                       ` Linlin Zhang
2026-10-13 18:08                         ` Michael S. Tsirkin
2026-10-13 19:07                         ` Stefan Hajnoczi
2026-10-12 23:12               ` Max Gurtovoy
2026-10-13 16:23                 ` Linlin Zhang
2026-10-13 18:07                   ` Max Gurtovoy
2026-10-13 18:10                     ` 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=20260917201647.GB331587@fedora \
    --to=stefanha@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=linlin.zhang@oss.qualcomm.com \
    --cc=neeraj.soni@oss.qualcomm.com \
    --cc=virtio-dev@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 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.