Windows: add gated direct I/O for mounted raw volumes

[0x1337F00D]

Summary

This adds a second, opt-in I/O path for mounted raw partitions and drives on Windows. The existing encrypted I/O queue remains the compatibility path; eligible raw-volume reads and writes can independently use a bounded direct path when their respective gates are enabled.

The implementation was developed and measured only in a Windows 11 ARM64 Parallels VM with a locally test-signed driver. It has not yet been validated on bare-metal NVMe hardware or on x64 Windows.

Related performance issue: #136.

Design

• Two independent, default-off registry gates:
  • VeraCryptEnableMountedVolumeFastReadIo
  • VeraCryptEnableMountedVolumeFastWriteIo
• Only mounted raw partitions/drives are eligible.
• File containers, system-encryption/filter I/O and unsupported requests keep the legacy queue.
• A separate asynchronous raw-device handle prevents direct requests from changing the synchronous semantics expected by the legacy path.
• Each mounted volume owns a bounded pool of 8 workers with at most 8 direct operations in flight.
• Requests up to 1 MiB are accepted and segmented according to the host device's actual maximum transfer and alignment constraints.
• Overlapping writes are range-ordered. Reads and writes cross explicit barriers where required, preserving visibility and flush/dismount ordering.
• Compatibility or eligibility failures fall back to the existing queue.
• Stop/dismount closes admission, drains queue-owned work, and retains remove-lock/outstanding ownership until each child IRP actually completes.

The lifetime model intentionally does not abandon a timed-out child IRP. This addresses the ownership problem discussed in prior direct-I/O work such as #1808.

Performance-counter IOCTLs used to prove path selection during development are intentionally excluded from this product PR; they remain isolated for a possible separate diagnostics PR.

Performance evidence

DiskSpd was run against the same 4 GiB file on a mounted raw test partition (W:), with the same profile order and arguments for legacy (gates off) and direct modes:

• Sequential: -d8 -W0 -C0 -b1M -o4 -t2 -Sh -L
• Random: -d8 -W0 -C0 -b4K -o32 -t4 -r -Sh -L
• Reads used -w0; writes used -w100

Profile	Legacy path	Direct path	Change
Sequential read	3232.81 MiB/s	5598.72 MiB/s	+73.18% (1.7318x)
Random read, 4 KiB	17,403.70 IOPS	37,960.88 IOPS	+118.12% (2.1812x)
Sequential write	1386.84 MiB/s	2277.34 MiB/s	+64.21% (1.6421x)
Random write, 4 KiB	6,104.56 IOPS	12,680.78 IOPS	+107.73% (2.0773x)

These figures are VM/cache/hypervisor-sensitive and must not be read as bare-metal NVMe claims. They demonstrate the relative bottleneck reduction in this test environment.

Counters in an instrumented sibling build confirmed that eligible bytes traversed the direct path. The final PR tree removes that counter ABI but retains the same direct-I/O data path plus the final lifetime/ordering hardening.

Stability and correctness checks

The evidence run completed with:

• 3 encrypted-system reboots without recovery
• 3 mount/dismount cycles
• chkdsk exit code 0
• unchanged file hash/marker across the matrix
• direct-path counter deltas for eligible profiles and zero idle deltas
• no re-encryption and no new VM snapshot

The final counter-free ARM64 Release driver also builds successfully (veracrypt.sys SHA-256 B1B625604BC8FDFF021F53260EEAC37C5D30E1F9D0FDC6D81C24BBE8915BCBB8).

Scope and requested review

This PR does not change the system/filter path, file-container path, or Windows storage identity/PnP behavior. It is specifically the dual-path performance change for already mounted raw volumes.

Review and measurements on bare-metal Windows, especially x64 and fast NVMe devices, would be very valuable before enabling either gate by default.