Re: [Qemu-devel] [PATCH v3 1/3] block: implement BDRV_REQ_PREFETCH

[Eric Blake]

On 7/25/19 5:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> Do effective copy-on-read request when we don't need data actually. It
> will be used for block-stream and NBD_CMD_CACHE.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> ---
>  include/block/block.h |  8 +++++++-
>  block/io.c            | 18 ++++++++++++------
>  2 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/include/block/block.h b/include/block/block.h
> index 50a07c1c33..73c3fc4daa 100644
> --- a/include/block/block.h
> +++ b/include/block/block.h
> @@ -88,8 +88,14 @@ typedef enum {
>       * fallback. */
>      BDRV_REQ_NO_FALLBACK        = 0x100,
>  
> +    /*
> +     * BDRV_REQ_PREFETCH may be used only together with BDRV_REQ_COPY_ON_READ
> +     * on read request and means that caller don't really need data to be

doesn't

can fix up while staging.


> +++ b/block/io.c
> @@ -1167,7 +1167,8 @@ bdrv_driver_pwritev_compressed(BlockDriverState *bs, 
> uint64_t offset,
>  }
>  
>  static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,
> -        int64_t offset, unsigned int bytes, QEMUIOVector *qiov)
> +        int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
> +        int flags)

We're bad about this, but 'int flags' does not play well with the C
language and well-defined behavior when it comes to 1<<31 (bit
operations and unsigned types have guaranteed behavior, bit operations
and negative signed types can cause the compiler to do differently than
you expect).  Not a problem for uses where we don't have 32 flags to OR
together, so I won't change it, so much as point it out for a bigger
task of auditing the entire code base if we are worried.

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

signature.asc
Description: OpenPGP digital signature