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
>
>
next prev parent 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