Add the new member supported_read_flags to BlockDriverState structure.
It will control the BDRV_REQ_PREFETCH flag set for copy-on-read
operations.

Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
---
 include/block/block_int.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/block/block_int.h b/include/block/block_int.h
index f782737..a142867 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -873,6 +873,10 @@ struct BlockDriverState {
     /* I/O Limits */
     BlockLimits bl;
 
+    /*
+     * Flags honored during pread (so far: BDRV_REQ_PREFETCH)
+     */
+    unsigned int supported_read_flags;
     /* Flags honored during pwrite (so far: BDRV_REQ_FUA,
      * BDRV_REQ_WRITE_UNCHANGED).
      * If a driver does not support BDRV_REQ_WRITE_UNCHANGED, those
-- 
1.8.3.1

On 12.10.20 19:43, Andrey Shinkevich wrote:
> Add the new member supported_read_flags to BlockDriverState structure.
> It will control the BDRV_REQ_PREFETCH flag set for copy-on-read
> operations.
> 
> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
> ---
>  include/block/block_int.h | 4 ++++
>  1 file changed, 4 insertions(+)

Not sure what the problem with passing BDRV_REQ_PREFETCH to drivers that
aren’t the COR filter are would be, but:

Reviewed-by: Max Reitz <mreitz@redhat.com>

(I mean, outside of the context of COR the flag is undefined, so it can
be anything, but intuitively I’d assume it means “no need to read the
data to memory” then, too.  So if a driver doesn’t support it, nothing
bad should happen.  Hm.  Well, unless the driver passes the flag on
(unsuspectingly) and a metadata-bearing child doesn’t return any data
that the drviver needs.  Yeah, better to explicitly disallow the flag
for all unsupporting drivers then.)