block: Assume sparse support for block devices - #7757
Conversation
Extend run_qemu_img() with an optional trailing_args parameter for arguments that follow the image path, such as the size in 'qemu-img create -f raw <path> 128M'. Signed-off-by: Anatol Belski <[email protected]>
Verify that a loopback block device advertises VIRTIO_BLK_F_DISCARD to the guest and that blkdiscard succeeds. Signed-off-by: Anatol Belski <[email protected]>
Verify that the guest remains stable when BLKDISCARD fails on the host backend. DM snapshot targets do not support discard, so the VMM returns VIRTIO_BLK_S_IOERR. The test retries blkdiscard several times, checking guest responsiveness after each attempt, then confirms normal I/O still works. The DM topology follows the same pattern used by WindowsDiskConfig. Signed-off-by: Anatol Belski <[email protected]>
The Windows tests use a DM snapshot device for the OS disk. DM snapshot targets do not support BLKDISCARD, so the VMM returns IOERR for every TRIM attempt. viostor.sys may BSOD when the host returns an error for negotiated discard/write-zeroes operations. Add a default_disks_sparse_off() helper to GuestCommand and use it in all Windows tests. Signed-off-by: Anatol Belski <[email protected]>
There is no non destructive readonly ioctl to query block device discard or write zeroes capabilities. BLKZEROOUT is guaranteed to succeed via kernel software fallback. BLKDISCARD may fail at runtime with EOPNOTSUPP on devices that lack trim support, but the error propagates to the guest as VIRTIO_BLK_S_IOERR and well behaved guests handle it gracefully. Signed-off-by: Anatol Belski <[email protected]>
|
Thanks for raising this, the code lgtm! do we want write_zeroes in the test cases too? i saw there is only discard |
|
I've been double checking - It can fail with I/O errors, but that's another situation. So there there seems to be no failure edge case to cover for write zeroes. The discard path is the one that can actually fail ( Thanks |
6404d2d
|
Hi, quick question, are we going to have a release with this fix? If so, may i know what is the planned release schedule? Seems i didn't find it in the repo, maybe i missed something |
This will be included in the next release - v52 - scheduled for April 23rd. |
|
Thank you! |
Block devices fail the sparse support probe because there is no non-destructive readonly ioctl to query discard/write-zeroes capabilities, so VIRTIO_BLK_F_DISCARD and VIRTIO_BLK_F_WRITE_ZEROES are never negotiated.
Unconditionally assume sparse support for block devices. This matches QEMU, where in
hw/block/virtio-blk.cset these features inhost_featureswithout probingDEFINE_PROP_BIT64("discard", ..., true)DEFINE_PROP_BIT64("write-zeroes", ..., true)Runtime failures return
VIRTIO_BLK_S_IOERR. Well behaved guests handle this gracefully.It is unclear whether QEMU has test coverage for topologies like DM snapshot where
BLKDISCARDis unsupported.Integration tests verify discard on a loop device and graceful
IOERRhandling on a DM snapshot topology. Windows tests disable sparse to avoidviostor.sysBSOD on unsupported discard. This also includes a small refactoring on the integration test side.Ref: #7750