block: Implement write_zeroes and punch_hole for AIO backend - #7817
Merged
Merged
Conversation
Member
|
Thanks for your contribution! @weltling could you support with with review please? |
The AIO block backend advertises VIRTIO_BLK_F_WRITE_ZEROES and VIRTIO_BLK_F_DISCARD to guests because the filesystem probe (supports_sparse_operations) returns true on ext4/XFS. However, RawFileAsyncAio::write_zeroes() and punch_hole() return errors because Linux AIO (io_submit) has no IOCB command for fallocate. When io_uring is unavailable (e.g. io_uring_disabled=2, a common security hardening on enterprise Linux), Cloud Hypervisor falls back to the AIO backend. The guest negotiates the feature, issues WRITE_ZEROES requests, and gets I/O errors. Implement write_zeroes and punch_hole using synchronous libc::fallocate() calls, matching the pattern used by the sync backend (RawFileSync). A VecDeque-based completion list signals results to the caller via the existing eventfd mechanism. Unit tests mirror the existing raw_sync.rs test suite. Integration tests add AIO-specific variants of the discard and fstrim tests using _disable_io_uring=on. Signed-off-by: Emir Beganovic <[email protected]>
emirb
force-pushed
the
fix/aio-write-zeroes
branch
from
March 10, 2026 19:06
a202215 to
5db7962
Compare
weltling
approved these changes
Mar 10, 2026
weltling
left a comment
Member
There was a problem hiding this comment.
The approach is fine - it's correct, simple, extends tests and matches the sync backend. Also it's the exact drop-in implementation that was meant to be filled one day, which turns out to be today :)
About the tests:
- The unit tests seem to be a verbatim copy from
raw_sync.rswith only diff in the constructor. That's not ideal but I'd say it's ok as the tests themselves aren't wrong. Probably next step would be to factor them out into a shared test helper. - A test for mixed AIO and sync completions would seem to be useful specifically for this patch, as
VecDequeis the required pattern in this implementation.
Thanks
rbradford
approved these changes
Mar 10, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Mar 11, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Mar 11, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Mar 11, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Mar 11, 2026
likebreath
approved these changes
Mar 11, 2026
likebreath
left a comment
Member
There was a problem hiding this comment.
This is a good feature gap to close. Thank you.
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Mar 11, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Mar 12, 2026
Member
|
Encountered this scary regression on Rocky Linux Host where Since |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Trying out an upgrade from v50 to v51 and found out what seems to be regression, affecting everyone on RHEL 9 or everyone with io_uring disabled.
In v50 and earlier,
VIRTIO_BLK_F_WRITE_ZEROESwas not advertised, so guests never issued these requests. v51 added the feature (#7666) with implementations for the io_uring and sync backends, but left the AIO backend as error stubs.The AIO block backend advertises VIRTIO_BLK_F_WRITE_ZEROES and VIRTIO_BLK_F_DISCARD to guests because RawFileDiskAio::supports_sparse_operations() probes the filesystem via fallocate() and returns true on ext4/XFS. However, RawFileAsyncAio::write_zeroes() and punch_hole() return errors because Linux AIO (io_submit) has no IOCB command for fallocate.
When io_uring is unavailable (e.g., kernel.io_uring_disabled=2, a common security hardening on enterprise Linux), Cloud Hypervisor falls back to the AIO backend. The guest negotiates the feature, issues WRITE_ZEROES requests, and gets I/O errors:
Guest dmesg:
Cloud Hypervisor log:
Tested on a host with XFS (with 4 raw disk images, long stroy...) and kernel io_uring_disabled=2 (disabled by default in Centos Stream 9)
After this patch, all WRITE_ZEROES I/O errors are eliminated and the VM boots cleanly. (tested after compiling the patch, on the same host)
The fix implements write_zeroes and punch_hole using synchronous libc::fallocate() calls, matching the pattern used by the sync backend (RawFileSync). Linux AIO has no IOCB command for fallocate, so the operations execute synchronously and completions are signaled via a VecDeque-based completion list and the existing eventfd mechanism, identical to how RawFileSync handles these operations.