From: Kevin Wolf <kwolf@redhat.com>
To: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: qemu-block@nongnu.org, hreitz@redhat.com, stefanha@redhat.com,
mst@redhat.com, devel@lists.libvirt.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v2 0/4] virtio-blk: Deprecate silent truncation of serial
Date: Fri, 13 Nov 2026 14:31:07 +0100 [thread overview]
Message-ID: <avcRG6PtcXbB0KvJ@redhat.com> (raw)
In-Reply-To: <259057b5-d900-4388-a4fc-b698860ba158@linux.ibm.com>
Am 09.11.2026 um 14:21 hat Christian Borntraeger geschrieben:
> Am 30.10.26 um 00:09 schrieb Kevin Wolf via Devel:
> > QEMU has allowed the user to specify serials of arbitrary length for
> > virtio-blk devices, even though the virtio-blk protocol can only
> > communicate 20 characters of the serial to the guest. This means that a
> > longer serial number on the command line is silently truncated to 20
> > characters from the guest perspective.
> >
> > As a first step to fix this, deprecate the silent truncation and turn it
> > into a warning; we can later make this a hard error. While touching
> > GET_ID, let's make it more spec compliant and clean up the internal
> > state.
> >
> > Another part is planned that will actually enable users to use longer
> > serials and additional device identifiers. This will need spec changes
> > and would take more time than we have until the QEMU 11.2 freeze anyway,
> > so I'll address this later. For now, the important thing is to get the
> > deprecation period started.
>
> Consider me interested for future extensions.
> Additional information via virtio-blk would be really helpful. e.g. when
> forwarding a scsi LUN having the WWID visible for virtio-blk would be really
> nice. One usecase is that the guest visible WWID can be used to talk to
> the storage server to create snapshots without having to have a translation
> table from guest virtio-blk device to WWID. This was actually a real ask from
> a customer.
So let's talk about what specific information to add while we touch the
spec. My first thought was adding whatever two or three things scsi-disk
offers in qdev, but after actually looking at the code and the spec I'm
not so sure any more. We seem to have:
- vendor, product (standard INQUIRY data)
- serial (VPD page 0x80)
- device_id (VPD page 0x83, vendor-specific descriptor for LUN)
- wwn (VPD page 0x83, 64 bit NAA descriptor for LUN)
- port_wwn (VPD page 0x83, 64 bit NAA descriptor for SAS target port)
- port_index (VPD page 0x83, relative target port identifier for SAS target port)
For comparison, IDE seems to have:
- serial
- model
- wwn (64 bit NAA descriptor)
As virtio-blk is a single-disk device, it probably makes sense to leave
out the non-LUN descriptors from SCSI.
It's also unclear to me that serial vs. device_id is something that
would make sense in the context of virtio-blk. I don't really know how
to explain an additional device_id in the spec and what would make it
different from serial.
Maybe something like vendor/product/model would make sense where we
would return "QEMU" and other implementations can return a different
string (e.g. if guest drivers have to work around bugs in a specific
implementation). Probably just a single field.
And then finally the WWID, where scsi-hd and ide-hd agree that it's a
64 bit number, but the SCSI spec is a lot more complicated. I think we
want to have this, but the exact format to use in the virtio spec isn't
entirely obvious. I've been thinking of maybe just referencing the SPC
and adding the SCSI name string to the spec, which can represent the
64 bit NAA identifiers supported by scsi-hd and ide-hd, but can also
express a few more things.
Any thoughts on all of this?
> virtio SCSI LUN passthru has that but it is significantly slower
> (factors) and that was also real feedback from that customer.
Does this mean that what the emulated scsi-hd offers is actually not
good enough, but you have to use passthrough to enable this use case?
What is the additional information they need?
Kevin
next prev parent reply other threads:[~2026-11-13 13:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 23:09 [PATCH v2 0/4] virtio-blk: Deprecate silent truncation of serial Kevin Wolf
2026-10-29 23:09 ` [PATCH v2 1/4] virtio-blk: Implement full NUL padding for GET_ID Kevin Wolf
2026-10-29 23:09 ` [PATCH v2 2/4] virtio-blk-test: Add a basic GET_ID test case Kevin Wolf
2026-10-30 19:30 ` Stefan Hajnoczi
2026-10-29 23:10 ` [PATCH v2 3/4] virtio-blk: Deprecate silent truncation of serial Kevin Wolf
2026-10-29 23:10 ` [PATCH v2 4/4] virtio-blk-test: Test truncated serial Kevin Wolf
2026-10-30 19:30 ` Stefan Hajnoczi
2026-10-30 19:31 ` [PATCH v2 0/4] virtio-blk: Deprecate silent truncation of serial Stefan Hajnoczi
2026-11-09 13:21 ` Christian Borntraeger
2026-11-13 13:31 ` Kevin Wolf [this message]
2026-11-13 16:39 ` Christian Borntraeger
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=avcRG6PtcXbB0KvJ@redhat.com \
--to=kwolf@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=devel@lists.libvirt.org \
--cc=hreitz@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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.