[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC 0/2] Split padded I/O vectors exceeding IOV_MAX
From: |
Hanna Czenczek |
Subject: |
[RFC 0/2] Split padded I/O vectors exceeding IOV_MAX |
Date: |
Wed, 15 Mar 2023 13:13:28 +0100 |
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
- [RFC 0/2] Split padded I/O vectors exceeding IOV_MAX,
Hanna Czenczek <=