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

["Michael S. Tsirkin" <mst@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>
> ---
>  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


I think it is time we folded this list with the defines below,
to avoid repetition, and help implementers:


	The type of the request is one of the following:
	....

	#define VIRTIO_BLK_T_GET_LIFETIME 10 /* get device lifetime */
	#define VIRTIO_BLK_T_DISCARD      11 /* discard */


> @@ -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
>  \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.

why 247? It feels like a lot, especially given we are padding. I'd say
128 maybe.  This way it fits in a single pci express packet on most
systems.

And as long as we are relaxing things, let's allow unicode?



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

Why first specifically?


> +
> +VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.

Until we add LONG_LONG_ID )

>  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.
> +
> +Device drivers MAY choose a mechanism to opt in to longer device IDs,
> +to prevent existing guests from breaking when they see a longer
> +(non-truncated) device ID.
>  In this case a guest which has not opted
> +in will continue to use VIRTIO_BLK_T_GET_ID and ignore the complete
> +ID.

But we don't know that the first 20 bytes are unique or descriptive
enough.

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