summary refs log tree commit diff stats
path: root/include/hw/mem/memory-device.h
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2018-05-03 17:26:26 -0500
committerEric Blake <eblake@redhat.com>2018-05-04 08:23:39 -0500
commitacfd8f7a5f92e703d2d046cbe3d510008a697194 (patch)
treebb47d2e1905f1760fb4a05b1479cde1e74c82740 /include/hw/mem/memory-device.h
parente475d108f1b3d3163f0affea67cdedbe5fc9752b (diff)
downloadfocaccia-qemu-acfd8f7a5f92e703d2d046cbe3d510008a697194.tar.gz
focaccia-qemu-acfd8f7a5f92e703d2d046cbe3d510008a697194.zip
nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply
The NBD spec is proposing a relaxation of NBD_CMD_BLOCK_STATUS
where a server may have the final extent per context give a
length beyond the original request, if it can easily prove that
subsequent bytes have the same status, on the grounds that a
client can take advantage of this information for fewer block
status requests.  Since qemu 2.12 as a client always sends
NBD_CMD_FLAG_REQ_ONE, and rejects a server that sends extra
length, the upstream NBD spec will probably limit this behavior
to clients that don't request REQ_ONE semantics; but it doesn't
hurt to relax qemu to always be permissive of this server
behavior, even if it continues to use REQ_ONE.

CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180503222626.1303410-1-eblake@redhat.com>
Reviewed-by:  Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Diffstat (limited to 'include/hw/mem/memory-device.h')
0 files changed, 0 insertions, 0 deletions