Dear Maintainer,

I have discovered that in the Debian 13 kernel (6.12.96-1) and newer, disk I/O in a QEMU Windows (2012/2016/2019/2025) guest is very poor, significantly worse than Debian 12's kernel.
It is so poor that it impacts on the normal use of Windows, things like browsing file explorer becomes a lot slower as well as application launching.

Random 4k (Q32T1) results from CrystalDiskMark show 58.05MB/s for read and 25.82MB/s for write.

I then changed the kernel used by Debian 13 to the same kernel that's used by Debian 12: 6.1.177-1, the issue disappears immediately and disk I/O performance is much improved:
CrystalDiskMark then shows 310.39MB/s for read and 254.51MB/s for write.

I also tested the Debian 14 kernel (7.1.3-1) but it has the same issue as 6.12.96-1.

Using Debian 12 as the base operating system is also fine, as long as its native kernel (6.1.177-1) is used.

This would suggest there has been a regression in the kernel between 6.1.177 and 6.12.96-1.

I am able to reproduce this issue on many different hardware configuirations and SSD types (consumer such as Kingston Fury Renegade and enterprise such as Samsung PM9A3).

QEMU: 10.0.11
Libvirt: 11.3.0
Disk Bus Type: VirtIO SCSI (others were tried, such as VirtIO Block, butd have the same issue)
Disk Driver IO Type: all were tried (threads, native, io_uring, none) and produced similar results
Windows veersion: 2012/2016/2019/2025 all show the issue

Thanks

Attached are crystaldiskmark results from the Windows guest while using
three different kernels on the Debian 13 host.

All tests were always performed with Debian 13 being used as the
host/hypervisor OS, the only thing that changed each time was the kernel
used.

Thanks

Hi Ryan,

As you can reproduce the regression with only the kernel changing on a
otherwise stable environment: Can you please bisect the issue to
pinpoint the upstream change introducing the behaviour you are seeing?

In this case as we have to jump over multiple versions released in
Debian you might first narrow down the range bit more by released
Debian packages (you can fetch them via snapshot.debian.org). Then
once the range is close enough go into the real git bisection.

Alternatively if you can reproduce the version both with upstream
released version 6.12 already, bisect beween v6.1 and v6.12 directly
upstream.

Let us know if you need any further assistance in how to proceed.

Regards,
Salvatore