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

["Richard W.M. Jones" <rjones@redhat.com>]

On Mon, Sep 07, 2026 at 03:56:56AM -0400, Michael S. Tsirkin wrote:
> 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.

virtio-scsi supports, at least in theory, 248 bytes, see:

https://gitlab.com/qemu/qemu/-/blob/cacd3462963a0a4f5bab4263ce79c2aa4b32692d/hw/scsi/scsi-disk.c#L708

This is chosen because of the maximum page size of a SCSI VPD (256)
minus the 8 bytes used for the header in VPD page 0x83.

Windows supports up to 128 "characters" and does support Unicode:

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

Although ...

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

... I feel we're just going to be introducing a world of pain by
trying to support Unicode, and I think anyone trying to use Unicode
serial numbers is doing it wrong.  Or anything outside numbers,
letters and dashes TBH.

Serials that I actually care about for my use case (converting from
VMware) are written as 32 hex characters, which VMware refers to as
"UUIDs" (they are actually encoded in binary by pvscsi but that's not
relevant here).

I think we could choose 247 or 248, but recommend that serials never
exceed 128 characters if implementers are concerned about
interoperability issues.  We still want to permit virtio-scsi serials
to be compatible with virtio-blk which argues for the larger sizes.

247 has the minor advantage that the response is always NUL-terminated.

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

For backwards compatibility (assuming I understand the question).
qemu's current behaviour is to truncate.

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

Sure, in fact we know it is _not_, which is exactly the reason to
introduce the longer serials.

I'm preparing a follow up which I'll post shortly.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org