From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: virtio-comment@lists.linux.dev, "Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v3 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned
Date: Tue, 8 Sep 2026 11:14:46 -0400 [thread overview]
Message-ID: <20260908151446.GC1016680@fedora> (raw)
In-Reply-To: <20260908094050.915173-2-rjones@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4307 bytes --]
On Tue, Sep 08, 2026 at 10:40:50AM +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 SCSI serials can in theory
> be this long. 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.
>
> A new feature bit is introduced to indicate that long device IDs are
> supported.
>
> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> ---
> device-types/blk/description.tex | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> index 3b3a4e7..aa3ec66 100644
> --- a/device-types/blk/description.tex
> +++ b/device-types/blk/description.tex
> @@ -73,6 +73,9 @@ \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_LONG_ID (20)] Device supports long device ID
> + strings.
> +
> \end{description}
>
> \subsubsection{Legacy Interface: Feature bits}\label{sec:Device Types / Block Device / Feature bits / Legacy Interface: Feature bits}
> @@ -516,8 +519,23 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> 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.
> +\field{data}. The device ID string is an ASCII string which can be
> +up to 247 bytes long.
> +
> +If VIRTIO_BLK_F_LONG_ID was not negotiated, 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.)
> +
> +If VIRTIO_BLK_F_LONG_ID was negotiated, VIRTIO_BLK_T_GET_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 is NUL terminated.
> +
> +Although 247 byte device ID strings are allowed, there may be
> +interoperability problems if strings longer than 128 bytes are used.
Can you be more specific? Is the concern that the guest software stack
above of the driver may not be prepared for serial strings longer than
128 bytes?
> +It is also advisable to use only 7 bit ASCII characters.
Versus "The device ID string is an ASCII string which can be up to 247
bytes long" earlier in this patch. Is ASCII a "SHOULD" or a "MUST"?
>
> The \field{data} used for VIRTIO_BLK_T_GET_LIFETIME requests is populated
> by the device, and is of the form
> @@ -911,7 +929,10 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> virtio_blk_discard_write_zeroes for VIRTIO_BLK_T_DISCARD,
> VIRTIO_BLK_T_SECURE_ERASE and VIRTIO_BLK_T_WRITE_ZEROES requests.
>
> -The length of \field{data} MUST be 20 bytes for VIRTIO_BLK_T_GET_ID requests.
> +For VIRTIO_BLK_T_GET_ID requests the length of \field{data} depends
> +on the feature VIRTIO_BLK_F_LONG_ID. If VIRTIO_BLK_F_LONG_ID was
> +negotiated the length of \field{data} MUST be 248 bytes, else
> +it MUST be 20 bytes.
>
> VIRTIO_BLK_T_DISCARD requests MUST NOT contain more than
> \field{max_discard_seg} struct virtio_blk_discard_write_zeroes segments in
> --
> 2.55.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-09-08 15:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 9:40 [PATCH v3 0/1] [PATCH v3] device-types/blk/description.tex: Allow longer device IDs to be returned Richard W.M. Jones
2026-09-08 9:40 ` [PATCH v3 1/1] " Richard W.M. Jones
2026-09-08 10:57 ` Michael S. Tsirkin
2026-09-08 11:51 ` Richard W.M. Jones
2026-09-08 14:16 ` Michael S. Tsirkin
2026-09-08 15:14 ` Stefan Hajnoczi [this message]
2026-09-08 15:46 ` Richard W.M. Jones
2026-09-08 16:43 ` Michael S. Tsirkin
2026-09-09 2:12 ` Demi Marie Obenour
2026-09-09 3:34 ` Parav Pandit
2026-09-09 7:07 ` Michael S. Tsirkin
2026-09-09 7:05 ` Michael S. Tsirkin
2026-09-08 16:25 ` Michael S. Tsirkin
[not found] ` <aq13FIJ3xzCGzqzq@redhat.com>
2026-09-19 22:17 ` Michael S. Tsirkin
2026-09-21 8:25 ` Richard W.M. Jones
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=20260908151446.GC1016680@fedora \
--to=stefanha@redhat.com \
--cc=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 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.