Re: [PATCH] block: make BlockConf.*_size properties 32-bit

[Eric Blake <eblake@redhat.com>]

On 2/11/20 5:54 AM, Roman Kagan wrote:
> Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> 32-bit for logical_block_size, physical_block_size, and min_io_size.
> However, the properties in BlockConf are defined as uint16_t limiting
> the values to 32768.
> 
> This appears unnecessary tight, and we've seen bigger block sizes handy
> at times.

What larger sizes?  I could see 64k or maybe even 1M block sizes,...

> 
> Make them 32 bit instead and lift the limitation.
> 
> Signed-off-by: Roman Kagan <rvkagan@yandex-team.ru>
> ---
>   hw/core/qdev-properties.c    | 21 ++++++++++++---------
>   include/hw/block/block.h     |  8 ++++----
>   include/hw/qdev-properties.h |  2 +-
>   3 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> index 7f93bfeb88..5f84e4a3b8 100644
> --- a/hw/core/qdev-properties.c
> +++ b/hw/core/qdev-properties.c
> @@ -716,30 +716,32 @@ const PropertyInfo qdev_prop_pci_devfn = {
>   
>   /* --- blocksize --- */
>   
> +#define MIN_BLOCK_SIZE 512
> +#define MAX_BLOCK_SIZE 2147483648

...but 2G block sizes are going to have tremendous performance problems.

I'm not necessarily opposed to the widening to a 32-bit type, but think 
you need more justification or a smaller number for the max block size, 
particularly since qcow2 refuses to use cluster sizes larger than 2M and 
it makes no sense to allow a block size larger than a cluster size.

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