[RFC 0/2] Split padded I/O vectors exceeding IOV_MAX

[Hanna Czenczek]

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