Re: [PATCH v3 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned

["Michael S. Tsirkin" <mst@redhat.com>]

Thanks for the patch! Yes something to improve:

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.

Judging by the below, it does not have to be ASCII? just a nul
terminated string?


247 is just a very weird limit.
So we get another
arbitrary number drivers need to worry about. Ugh.
I just don't get all the references
to scsi vpd or whatever. It's your motivation I get that
but we should not set policy.

Let's just simply limit the string to  255 bytes and
make data 255 bytes too?
Then with the status byte the write buffer fits in a 256 pcie packet.

Maybe others feel differently.

> +
> +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.)

But the driver can not both negotiate and not negotiate
VIRTIO_BLK_F_LONG_ID.

So what does this requirement that the two configs share
a prefix buy us, practically?

Why don't we just say that the ID is up to either 20 bytes or
255 bytes depending on the feature negotiation?


> +
> +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.

Let's just handle short and long forms consistently please.
If the string fills all of data then it is not terminated. end of story.

All the subtle differences are just a source for confusion.  Can we not
define something like "maximum ID length" and then use it everywhere,
instead of all the duplication?

> +
> +Although 247 byte device ID strings are allowed, there may be
> +interoperability problems if strings longer than 128 bytes are used.

I think you mean 127? so it's 128 with the NUL.

> +It is also advisable to use only 7 bit ASCII characters.

ASCII == 7 bit. Maybe you mean printable characters?


Pls add both these recommendations in the conformance section.


>  
>  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