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

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

On Mon, Sep 07, 2026 at 03:02:24PM +0100, Richard W.M. Jones wrote:
> 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.

Can I see a spec which says that is the maximum size?

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

Really anything close to NAME_MAX is already a world of pain
for guests.


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

That's just a qemu command line quirk then.
At least from spec POV it isn't - the id must be <= 20.

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