Default NVMe MDTS value causes Widnows Server 2025 hangs and BSODs (during install at least)

["Roger Pau Monné" <roger.pau@citrix.com>]

Hello,

As part of XenServer Windows Server 2025 testing using Xen plus QEMU
we discovered an issue during install that would lead to either the
Windows installer getting stuck without making progress (albeit the
screen was still showing the spinning circle correctly) or a BSOD that
doesn't seem to have a unique number, the most common one was 0x50
(PAGE_FAULT_IN_NONPAGED_AREA).

After a fair amount of debugging and following incorrect leads we have
narrowed down what triggers the issue to QEMU emulated NVMe reporting
a MDTS value of 7 by default (so max request size of 512KiB).
Switching to higher MDTS values seemed to solve the issue.

The commit that made that change:

e137d20e7dff hw/block/nvme: add check for mdts

Didn't contain much justification for the change from unlimited to
512KiB max request size.

Windows is like a black box to me, but I believe there's some error in
the Windows logic that splits requests, and hence when MDTS is set to
a sufficiently low value, and Windows has to split NVMe requests, it
causes Windows to hit an internal bug.  This will be raised with
Microsoft to get the issue debugged and possibly fixed on their side.

From limited experimentation setting mdts to 10 (so 4MiB max request
size) or 9 (2MiB) workarounds the issue.

Would it be acceptable for QEMU NVMe to consider increasing the
default MDTS value to something higher than 7 to workaround the issue?
I've tested both 9 and 10 and they prevent the issue, I would avoid 8
as it's too close to the current one that causes issues.  I don't have
many references of other emulated NVMe implementations, I just know
about Bhyve emulated NVMe, which sets MDTS to 9.

If bumping MDTS to a higher value is acceptable please let me know and
I will prepare a patch.

Regards, Roger.