Re: [PATCH 1/8] block: move has_variable_length to BlockLimits

[Eric Blake]

On Fri, Apr 07, 2023 at 05:32:56PM +0200, Paolo Bonzini wrote:
> At the protocol level, has_variable_length only needs to be true in the
> very special case of host CD-ROM drives, so that they do not need an
> explicit monitor command to read the new size when a disc is loaded
> in the tray.
> 
> However, at the format level has_variable_length has to be true for all
> raw blockdevs and for all filters, even though in practice the length
> depends on the underlying file and thus will not change except in the
> case of host CD-ROM drives.
> 
> As a first step towards computing an accurate value of has_variable_length,
> add the value into the BlockLimits structure and initialize the field
> from the BlockDriver.

My assumption here is that all other resizes (such as a block device
that can be externally enlarged upon seeing the guest pause due to an
ENOSPC condition on the current size) are NOT expected to have
automatic reaction in qemu, but instead rely on some other external
action (such as resuming after ENOSPC or an explicit monitor command)
as the reason for why qemu eventually learns the new size.  If my
assumption is right, then you do sound correct in stating that CDROMs
are special in that the guest OS can request the tray to be loaded and
change the size from 0 to the size of the newly-inserted disc, with no
intervening action or QMP command, and qemu must react to that size
change.

I'm asking because at one point, there was a proposal to extend the
NBD protocol to allow dynamic resizing, somewhat similar to how a
block device can be externally resized; there were questions on how
much of a resize action has to be from client-to-server "please poll
if the server has changed size recently" instead of server-to-client
"by the way, the size just changed".  I don't want NBD resize (if
someone ever fleshes out the extension propsal into an actual
implementation) to be hamstrung by an inability to reflect size
changes initiated on the server side, rather than triggered at the
client side.  But since I think regular files and block devices have
the same considerations, I don't think it is a show-stopper to this
series.

> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  block.c                          | 2 +-
>  block/io.c                       | 6 ++++++
>  include/block/block_int-common.h | 8 ++++++++
>  3 files changed, 15 insertions(+), 1 deletion(-)

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org