Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: virtio-comment@lists.linux.dev
Subject: Re: [PATCH 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned
Date: Sun, 6 Sep 2026 11:13:39 -0400	[thread overview]
Message-ID: <20260906110725-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260906145444.127570-2-rjones@redhat.com>

On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
> SCSI-based paravirtualized block devices including virtio-scsi and
> VMware's pvscsi allow longer device IDs.  This presents an issue when
> we change the backing of a disk from one type to another, eg from
> pvscsi to virtio-blk, or virtio-scsi to virtio-blk.  The longer device
> ID has to be truncated to 20 bytes.  This results in guest visible
> changes, notably /dev/disk/by-id/ paths are different, so any
> mountpoints or configuration files that use these paths will break.
> 
> Therefore extend virtio-blk to allow longer device IDs.  I chose 247
> bytes (ASCII chars) as the new limit since it can cope with any SCSI
> device serial.  Real serials will be much shorter than this; the aim
> is to allow UUIDs to be preserved which would use 32 or 36 ASCII
> chars.
> 
> We have to be cautious about breaking existing guests where the
> hypervisor is currently silently truncating a longer ID to 20 bytes.
> I suggest in the specification that virtio-blk device drivers allow a
> way to opt in to longer IDs, but this is ultimately up to the guests /
> drivers to decide.
> 
> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>

With 1 patch pls dont use a cover letter next time.
And Pls Cc relevant people)

> ---
>  device-types/blk/description.tex | 32 +++++++++++++++++++++++++-------
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> index 3b3a4e7..d42ca21 100644
> --- a/device-types/blk/description.tex
> +++ b/device-types/blk/description.tex
> @@ -457,9 +457,9 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  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
> -string command (VIRTIO_BLK_T_GET_ID), a secure erase
> -(VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime command
> -(VIRTIO_BLK_T_GET_LIFETIME).
> +string command (VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID),
> +a secure erase (VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime
> +command (VIRTIO_BLK_T_GET_LIFETIME).
>  
>  \begin{lstlisting}
>  #define VIRTIO_BLK_T_IN           0
> @@ -469,7 +469,8 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  #define VIRTIO_BLK_T_GET_LIFETIME 10
>  #define VIRTIO_BLK_T_DISCARD      11
>  #define VIRTIO_BLK_T_WRITE_ZEROES 13
> -#define VIRTIO_BLK_T_SECURE_ERASE   14
> +#define VIRTIO_BLK_T_SECURE_ERASE 14
> +#define VIRTIO_BLK_T_GET_LONG_ID  32


U also want a feature bit otherwise driver does not know if it's safe to
send VIRTIO_BLK_T_GET_LONG_ID.

>  \end{lstlisting}
>  
>  The \field{flags} bitfield is ignored by the device unless
> @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  the device to discard the specified range, provided that following reads return
>  zeroes.
>  
> -VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
> -\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
> -long.  If the string is 20 bytes long then there is no NUL terminator.
> +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> +device ID string from the device into \field{data}.  The device ID
> +string is an ASCII string which can be up to 247 bytes long.
> +
> +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> +string.  If the ID is shorter than 20 bytes, then the response is
> +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> +is 20 bytes or longer, this means the response will not be NUL
> +terminated.)
> +
> +VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.  The
> +response is always 248 bytes long, padded to this length with NUL
> +bytes.  Since the longest permitted device ID string is 247 bytes, the
> +response MUST be NUL terminated.

That's a lot of padding) Sure u do not want to use the actual length?

And pls avoid MUST outside conformance statements.
Here "is NUL terminated".

> +
> +Device drivers MAY choose a mechanism to opt in to longer device IDs,

same here, avoid MAY

> +to prevent existing guests

existing where?

> from breaking when they see a longer
> +(non-truncated) device ID.  In this case a guest which has not opted

avoid "guest"

> +in will continue to use VIRTIO_BLK_T_GET_ID

continue in what sense?

> and ignore the complete
> +ID.


No idea what does the above imply.

Maybe add conformance statements that say exactly what you mean.



>  
>  The \field{data} used for VIRTIO_BLK_T_GET_LIFETIME requests is populated
>  by the device, and is of the form
> -- 
> 2.55.0
> 
> 


  reply	other threads:[~2026-09-06 15:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-06 14:54 [PATCH 0/1] [PATCH] device-types/blk/description.tex: Allow longer device IDs to be returned Richard W.M. Jones
2026-09-06 14:54 ` [PATCH 1/1] " Richard W.M. Jones
2026-09-06 15:13   ` Michael S. Tsirkin [this message]
2026-09-06 16:06     ` Richard W.M. Jones
2026-09-07  7:33       ` Michael S. Tsirkin
2026-09-07  7:56   ` Michael S. Tsirkin
2026-09-07 14:02     ` Richard W.M. Jones
2026-09-07 19:27       ` Michael S. Tsirkin
2026-09-08  9:35         ` Richard W.M. Jones
2026-09-08 10:06           ` Michael S. Tsirkin
2026-09-08 10:43             ` Richard W.M. Jones
2026-09-08 10:57               ` 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=20260906110725-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=rjones@redhat.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