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

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

On Sun, Sep 06, 2026 at 05:06:25PM +0100, Richard W.M. Jones wrote:
> On Sun, Sep 06, 2026 at 11:13:39AM -0400, Michael S. Tsirkin wrote:
> > On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
> [...]
> > U also want a feature bit otherwise driver does not know if it's safe to
> > send VIRTIO_BLK_T_GET_LONG_ID.
> 
> Interestingly (at least for Linux) sending VIRTIO_BLK_T_GET_LONG_ID
> when the hypervisor doesn't support it returns -EOPNOTSUPP, but I can
> add a feature bit as well.
> 
> > >  \end{lstlisting}
> > >  
> > >  The \field{flags} bitfield is ignored by the device unless
> > > @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> > >  the device to discard the specified range, provided that following reads return
> > >  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.
> > > +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> > > +device ID string from the device into \field{data}.  The device ID
> > > +string is an ASCII string which can be up to 247 bytes long.
> > > +
> > > +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.)
> > > +
> > > +VIRTIO_BLK_T_GET_LONG_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 MUST be NUL terminated.
> > 
> > That's a lot of padding) Sure u do not want to use the actual length?
> 
> I'm not too clear on this (and the spec is also unclear), but it seems
> the buffer is allocated in the guest RAM?



Yes. But the driver specifies the length to the device.
So do we need a new type of request? We could just
change the length depending on a feature bit.


>  In that case since it
> doesn't know the length in advance it must allocate a fixed size buffer.
> 
> [...]

That's certainly the simplest way to do it, so that's what the spec
does:

The length of \field{data} MUST be 20 bytes for VIRTIO_BLK_T_GET_ID requests.




> > > +(non-truncated) device ID.  In this case a guest which has not opted
> > 
> > avoid "guest"
> 
> Is "driver" preferred?


yes

> I'll send a follow up addressing your other points, but probably not today.
> 
> Rich.

I have some more comments from reading more about it.

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