Hi, We accept I/O vectors with up to 1024 (IOV_MAX) elements from guests. When a guest request does not conform to the underlying storage's alignment requirements, we pad it with head and/or tail buffers as necessary, which are simply appended to the I/O vector.
As of 4c002cef, we (sensibly) check that such-padded vectors do not then exceed IOV_MAX. However, there seems to be no sensible error handling; instead, the guest simply receives an I/O error. Thatâs a problem, because it submitted a perfectly sensible I/O request (which adhered to the alignment the guest device has announced), but receives an error back. That shouldnât happen. I think we need to handle such excess lengths internally, but Iâm not sure how exactly. What I can think of is either breaking up the request into two (which seems like it might cause side effects) or to join up to three vector elements into one, using a bounce buffer. The latter seemed simpler to me, so this RFC does that. Still, itâs an RFC because I donât know whether thatâs the ideal solution. Hanna Czenczek (2): block: Split padded I/O vectors exceeding IOV_MAX iotests/iov-padding: New test block/io.c | 139 ++++++++++++++++++++++- util/iov.c | 4 - tests/qemu-iotests/tests/iov-padding | 85 ++++++++++++++ tests/qemu-iotests/tests/iov-padding.out | 59 ++++++++++ 4 files changed, 277 insertions(+), 10 deletions(-) create mode 100755 tests/qemu-iotests/tests/iov-padding create mode 100644 tests/qemu-iotests/tests/iov-padding.out -- 2.39.1
