On 18.03.23 13:39, Eric Blake wrote:
On Fri, Mar 17, 2023 at 06:50:19PM +0100, Hanna Czenczek wrote:
Test that even vectored IO requests with 1024 vector elements that are
not aligned to the device's request alignment will succeed.
Signed-off-by: Hanna Czenczek <hre...@redhat.com>
---
+
+# Four combinations:
+# - Offset 4096, length 1023 * 512 + 512: Fully aligned to 4k
+# - Offset 4096, length 1023 * 512 + 4096: Head is aligned, tail is not
Making sure I understand - we don't care if intermediate iovs are
smaller than the alignment requirement, because the scatter-gather
effects will pool it together and our overall request is still
aligned. Correct?
Not trivial to answer, but the short answer is that we don’t care.
The long answer: Padding is only done for head and tail, so intermediate
alignment doesn’t matter – for the interface. Internally, it does
actually matter, because every single buffer in the vector must be
aligned to the memory alignment, and its length must be aligned to the
request alignment (bdrv_qiov_is_aligned()). If those requirements aren’t
met, the file-posix driver will mark the request as QEMU_AIO_MISALIGNED,
and emulate it (with many separate writes) instead of handing it over to
a kernel interface that would take the full vector.
That doesn’t really matter for the test, but explains why this was no
issue before we decided to actually internally limited I/O vectors to
1024 elements: If the guest sees a smaller request alignment than the
host has, and then submits a 1024-element vectored request, there is for
sure going to be some buffer in those 1024 elements that isn’t fully
aligned. Therefore, qemu will emulate the request, and so it doesn’t
matter whether we increased its length past 1024 elements.
So what it does mean for the test is that these requests’ I/O vectors
are never going to be passed to the kernel as-is, so that code path
isn’t exercised. But, as laid out in the previous paragraph, that code
path isn’t exercised with guest OSs either.
Reviewed-by: Eric Blake <ebl...@redhat.com>
Thanks!
