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

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

[Richard W.M. Jones]

v3 considerably simplifies everything.  We now use the feature bit
(VIRTIO_BLK_F_LONG_ID) to decide if the driver will provide a 20 or
248 byte buffer to VIRTIO_BLK_T_GET_ID.

VIRTIO_BLK_T_GET_LONG_ID has been dropped.

There is a working implementation of this here:

https://github.com/rwmjones/virtio-spec/commits/2026-virtio-blk-long-id/
https://gitlab.com/rwmjones/qemu/-/commits/2026-virtio-blk-long-id?ref_type=heads
https://github.com/rwmjones/linux/commits/2026-virtio-blk-long-id/

Rich.

Richard W.M. Jones (1):
  device-types/blk/description.tex: Allow longer device IDs to be
    returned

 device-types/blk/description.tex | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

-- 
2.55.0

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

[Richard W.M. Jones]

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.
+It is also advisable to use only 7 bit ASCII characters.
 
 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

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

[Michael S. Tsirkin]

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

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

[Richard W.M. Jones]

On Tue, Sep 08, 2026 at 06:57:08AM -0400, Michael S. Tsirkin wrote:
> Thanks for the patch! Yes something to improve:
> 
> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> >  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?

I wonder actually if 128 is better.  It fits within the Windows limit
and it doesn't hurt for Linux either because of NAME_MAX limitations
that you would encounter with udev.

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

Interesting .. so I think I misunderstood how feature negotiation
works.  I _thought_ that the driver sends back features it
understands, via the features array:

https://github.com/torvalds/linux/blob/28924df2a08f440c73991b83028032c901de2ae4/drivers/block/virtio_blk.c#L1669

and therefore the host side can see if the driver supports
VIRTIO_BLK_F_LONG_ID.  Is that not how it works?

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

We can just drop the "first" language.

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

Sure.

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

OK.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

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

[Michael S. Tsirkin]

On Tue, Sep 08, 2026 at 12:51:08PM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 08, 2026 at 06:57:08AM -0400, Michael S. Tsirkin wrote:
> > Thanks for the patch! Yes something to improve:
> > 
> > On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> > >  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?
> 
> I wonder actually if 128 is better.  It fits within the Windows limit
> and it doesn't hurt for Linux either because of NAME_MAX limitations
> that you would encounter with udev.

Up to you. I actually take it back about trying to cut out the
last byte - no driver seems to combine status and data, let's just
make data a power of 2 in size.


> > 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.
> 
> Interesting .. so I think I misunderstood how feature negotiation
> works.  I _thought_ that the driver sends back features it
> understands, via the features array:
> 
> https://github.com/torvalds/linux/blob/28924df2a08f440c73991b83028032c901de2ae4/drivers/block/virtio_blk.c#L1669
> 
> and therefore the host side can see if the driver supports
> VIRTIO_BLK_F_LONG_ID.  Is that not how it works?

Yes. I am just saying there are drivers with VIRTIO_BLK_F_LONG_ID
that see the long id or without that see short one.
No one checks both so there is no need to constrain how
they are related.

> 
> > 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?
> 
> We can just drop the "first" language.

I like that.

> > > +
> > > +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?
> 
> Sure.
> 
> > > +
> > > +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.
> 
> OK.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> nbdkit - Flexible, fast NBD server with plugins
> https://gitlab.com/nbdkit/nbdkit

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

[Stefan Hajnoczi]

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

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

[Richard W.M. Jones]

On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> > +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?

I'll add more detail in the next version, but in brief the problems
are twofold:

(1) Windows supports up to 128 "characters" (they're not precise but
they probably mean Unicode codepoints from the Basic Multilingual Plane):

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number

(2) When udev tries to encode a very long serial into a
/dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).

> > +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"?

It's "SHOULD".  I can't see any good coming from trying to use
anything except letters, numbers and dashes in a serial, but both
Linux and Windows (see above) could in theory handle Unicode.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

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

[Michael S. Tsirkin]

On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> 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"?

Without VIRTIO_BLK_F_LONG_ID it's a MUST I would say, since drivers
might have relied on that. With VIRTIO_BLK_F_LONG_ID we can relax this.


udev has a set of baroque rules what is allowed
in the serial everything else it replaces with _'s


int allow_listed_char_for_devnode(char c, const char *additional) {
        return
                ascii_isdigit(c) ||
                ascii_isalpha(c) ||
                strchr("#+-.:=@_", c) ||
                (additional && strchr(additional, c));
}


additional is / and space

and it allows \x followed by 2 hex digits.


And it allows any multi-byte utf-8


So in fact unicode is safer than ascii.


Does not seem like something we want in the spec to be frank.



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

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

[Michael S. Tsirkin]

On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> > On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> > > +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?
> 
> I'll add more detail in the next version, but in brief the problems
> are twofold:
> 
> (1) Windows supports up to 128 "characters" (they're not precise but
> they probably mean Unicode codepoints from the Basic Multilingual Plane):
> 
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
> 
> (2) When udev tries to encode a very long serial into a
> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
> 
> > > +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"?
> 
> It's "SHOULD".  I can't see any good coming from trying to use
> anything except letters, numbers and dashes in a serial, but both
> Linux and Windows (see above) could in theory handle Unicode.
> 
> Rich.


Linux actually has code to try and handle that. unicode
is actually the less problematic part - ascii is
full of pitfalls, eith things like
slashes are much weirder - e.g. udev will create
a subdirectory with slashes. what will windows do?
and what will it do with backslashes? /me shrugs

> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2065 bytes --]

On 9/8/26 12:43, Michael S. Tsirkin wrote:
> On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
>> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
>>> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
>>>> +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?
>>
>> I'll add more detail in the next version, but in brief the problems
>> are twofold:
>>
>> (1) Windows supports up to 128 "characters" (they're not precise but
>> they probably mean Unicode codepoints from the Basic Multilingual Plane):
>>
>> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
>>
>> (2) When udev tries to encode a very long serial into a
>> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
>>
>>>> +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"?
>>
>> It's "SHOULD".  I can't see any good coming from trying to use
>> anything except letters, numbers and dashes in a serial, but both
>> Linux and Windows (see above) could in theory handle Unicode.
>>
>> Rich.
> 
> 
> Linux actually has code to try and handle that. unicode
> is actually the less problematic part - ascii is
> full of pitfalls, eith things like
> slashes are much weirder - e.g. udev will create
> a subdirectory with slashes. what will windows do?
> and what will it do with backslashes? /me shrugs

What about /../../../../../../../../..?

Honestly, the simplest way to protect against problems is to
just use a hex-encoded or base32-encoded cryptographic hash as
the name.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Parav Pandit]

> From: Demi Marie Obenour <demiobenour@gmail.com>
> Sent: 09 September 2026 07:42 AM


> On 9/8/26 12:43, Michael S. Tsirkin wrote:
> > On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
> >> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> >>> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> >>>> +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?
> >>
> >> I'll add more detail in the next version, but in brief the problems
> >> are twofold:
> >>
> >> (1) Windows supports up to 128 "characters" (they're not precise but
> >> they probably mean Unicode codepoints from the Basic Multilingual Plane):
> >>
> >> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
> >>
> >> (2) When udev tries to encode a very long serial into a
> >> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
> >>
> >>>> +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"?
> >>
> >> It's "SHOULD".  I can't see any good coming from trying to use
> >> anything except letters, numbers and dashes in a serial, but both
> >> Linux and Windows (see above) could in theory handle Unicode.
> >>
> >> Rich.
> >
> >
> > Linux actually has code to try and handle that. unicode
> > is actually the less problematic part - ascii is
> > full of pitfalls, eith things like
> > slashes are much weirder - e.g. udev will create
> > a subdirectory with slashes. what will windows do?
> > and what will it do with backslashes? /me shrugs
> 
> What about /../../../../../../../../..?
> 
> Honestly, the simplest way to protect against problems is to
> just use a hex-encoded or base32-encoded cryptographic hash as
> the name.
> --
Any issues in just using the UUID format?

> Sincerely,
> Demi Marie Obenour (she/her/hers)

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

[Michael S. Tsirkin]

On Tue, Sep 08, 2026 at 10:12:03PM -0400, Demi Marie Obenour wrote:
> On 9/8/26 12:43, Michael S. Tsirkin wrote:
> > On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
> >> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> >>> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> >>>> +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?
> >>
> >> I'll add more detail in the next version, but in brief the problems
> >> are twofold:
> >>
> >> (1) Windows supports up to 128 "characters" (they're not precise but
> >> they probably mean Unicode codepoints from the Basic Multilingual Plane):
> >>
> >> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
> >>
> >> (2) When udev tries to encode a very long serial into a
> >> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
> >>
> >>>> +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"?
> >>
> >> It's "SHOULD".  I can't see any good coming from trying to use
> >> anything except letters, numbers and dashes in a serial, but both
> >> Linux and Windows (see above) could in theory handle Unicode.
> >>
> >> Rich.
> > 
> > 
> > Linux actually has code to try and handle that. unicode
> > is actually the less problematic part - ascii is
> > full of pitfalls, eith things like
> > slashes are much weirder - e.g. udev will create
> > a subdirectory with slashes. what will windows do?
> > and what will it do with backslashes? /me shrugs
> 
> What about /../../../../../../../../..?

what do you want to know, whether it's valid?

the answer is no - systemd validates paths and will not
attempt to create paths it considers invalid, such as ones with dots.

That code is in path-util.h,

https://github.com/systemd/systemd/blob/main/src/basic/path-util.h

peruse it if you want to know more.

> Honestly, the simplest way to protect against problems is to
> just use a hex-encoded or base32-encoded cryptographic hash as
> the name.

I don't know that it's simplest, but yes, some do that.
Other subsets are safe, too.  But as I said,
unicode multibyte codepoints are not really problematic at all.


-- 
MST

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

[Michael S. Tsirkin]

On Wed, Sep 09, 2026 at 03:34:25AM +0000, Parav Pandit wrote:
> 
> 
> > From: Demi Marie Obenour <demiobenour@gmail.com>
> > Sent: 09 September 2026 07:42 AM
> 
> 
> > On 9/8/26 12:43, Michael S. Tsirkin wrote:
> > > On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
> > >> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> > >>> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> > >>>> +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?
> > >>
> > >> I'll add more detail in the next version, but in brief the problems
> > >> are twofold:
> > >>
> > >> (1) Windows supports up to 128 "characters" (they're not precise but
> > >> they probably mean Unicode codepoints from the Basic Multilingual Plane):
> > >>
> > >> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
> > >>
> > >> (2) When udev tries to encode a very long serial into a
> > >> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
> > >>
> > >>>> +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"?
> > >>
> > >> It's "SHOULD".  I can't see any good coming from trying to use
> > >> anything except letters, numbers and dashes in a serial, but both
> > >> Linux and Windows (see above) could in theory handle Unicode.
> > >>
> > >> Rich.
> > >
> > >
> > > Linux actually has code to try and handle that. unicode
> > > is actually the less problematic part - ascii is
> > > full of pitfalls, eith things like
> > > slashes are much weirder - e.g. udev will create
> > > a subdirectory with slashes. what will windows do?
> > > and what will it do with backslashes? /me shrugs
> > 
> > What about /../../../../../../../../..?
> > 
> > Honestly, the simplest way to protect against problems is to
> > just use a hex-encoded or base32-encoded cryptographic hash as
> > the name.
> > --
> Any issues in just using the UUID format?

Not as such, you can use it if you want. limiting ourselves to that
isn't addressing what Rich is trying to address, which is a lot
of legacy guests, since there are lots of users with lots of different ideas
what a serial should be.


> > Sincerely,
> > Demi Marie Obenour (she/her/hers)