From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: virtio-comment@lists.linux.dev
Subject: Re: [PATCH 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned
Date: Tue, 8 Sep 2026 06:06:14 -0400 [thread overview]
Message-ID: <20260908053922-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260908093534.GT1436@redhat.com>
On Tue, Sep 08, 2026 at 10:35:34AM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 07, 2026 at 03:27:25PM -0400, Michael S. Tsirkin wrote:
> > 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?
>
> I don't think virtio-scsi is following a spec,
But you referred to SCSI VPD and said it has a limit of 256
and an 8 byte header. I can't figure out where this is from?
> but it's clear from the
> source code that the limit is 256-8, see the link above.
>
> [...]
Hmm. I see MAX_SERIAL_LEN which is 36? And MAX_SERIAL_LEN_FOR_DEVID
which is 20?
> > > > > +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.
>
> Isn't the virtio spec also there (partly) to clarify and formalise
> what existing implementations actually do? qemu truncates.
> Firecracker truncates:
>
> https://github.com/firecracker-microvm/firecracker/blob/7699746649826d1dfcdde626b3131bac08f28e0d/src/vmm/src/devices/virtio/block/virtio/device.rs#L159
>
> libkrun seems to be using the same code as Firecracker, so it also
> truncates:
>
> https://github.com/libkrun/libkrun/blob/413a011760b7ee61493fb0073f7810319ca6a181/src/devices/src/virtio/block/device.rs#L170
I can easily imagine a situation where someone prefixes the serial
with "virtio-" or whatever extra data, and shows the suffix
as the short id. Or hashes the short id. Or whatever.
> I have a v3 which considerably simplifies the specification &
> implementation which I'll post very soon.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines. Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
next prev parent reply other threads:[~2026-09-08 10:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 14:54 [PATCH 0/1] [PATCH] device-types/blk/description.tex: Allow longer device IDs to be returned Richard W.M. Jones
2026-09-06 14:54 ` [PATCH 1/1] " Richard W.M. Jones
2026-09-06 15:13 ` Michael S. Tsirkin
2026-09-06 16:06 ` Richard W.M. Jones
2026-09-07 7:33 ` Michael S. Tsirkin
2026-09-07 7:56 ` Michael S. Tsirkin
2026-09-07 14:02 ` Richard W.M. Jones
2026-09-07 19:27 ` Michael S. Tsirkin
2026-09-08 9:35 ` Richard W.M. Jones
2026-09-08 10:06 ` Michael S. Tsirkin [this message]
2026-09-08 10:43 ` Richard W.M. Jones
2026-09-08 10:57 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260908053922-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=rjones@redhat.com \
--cc=virtio-comment@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.