Re: [Qemu-devel] [PATCH v2 05/13] block: Switch to 64-bit bl.max_transfer

[Eric Blake <eblake@redhat.com>]

On 11/15/18 9:45 AM, Kevin Wolf wrote:
> Am 15.11.2018 um 03:03 hat Eric Blake geschrieben:
>> This change has no semantic impact: all drivers either leave the
>> value at 0 (no inherent 32-bit limit is still translated into
>> fragmentation below 2G; see the previous patch for that audit), or
>> set it to a value less than 2G.  However, switching to a larger
>> type and enforcing the 2G cap at the block layer makes it easier
>> to audit specific drivers for their robustness to larger sizing,
>> by letting them specify a value larger than INT_MAX if they have
>> been audited to be 64-bit clean.
>>

>> +++ b/block/io.c
>> @@ -159,6 +159,13 @@ void bdrv_refresh_limits(BlockDriverState *bs, Error **errp)
>>       if (drv->bdrv_refresh_limits) {
>>           drv->bdrv_refresh_limits(bs, errp);
>>       }
>> +
>> +    /* Clamp max_transfer to 2G */
>> +    if (bs->bl.max_transfer > UINT32_MAX) {
> 
> UINT32_MAX is 4G, not 2G.
> 
> Would it make more sense to make BDRV_REQUEST_MAX_BYTES the maximum
> anyway?

D'oh.  Yes, that's what I intended, possibly by spelling it INT_MAX (the 
fact that the 'if' goes away in patch 13 is not an excuse for sloppy 
coding in the meantime).

> Allowing higher (but not too high) explicit values than what we
> clamp to feels a bit odd.
> 
> BDRV_REQUEST_MAX_BYTES is probably also what drivers really expect
> today.

Correct.  Well, at least the unaudited drivers (the rest of this series 
audits a few drivers that can handle larger byte values).

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