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

[Eric Blake]

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