# virtio-win/kvm-guest-drivers-windows: what the source tree actually contains > The KVM/QEMU Windows guest drivers ship as the virtio-win RPM and as distribution-neutral ISO and VFD images. This is a review of the source repository, who should build from it, and why most people should not. **virtio-win/kvm-guest-drivers-windows** — Windows paravirtualized drivers for QEMU\KVM - Repository: https://github.com/virtio-win/kvm-guest-drivers-windows - Website: https://www.linux-kvm.org/page/WindowsGuestDrivers - Stars: 2,719 · Forks: 476 - Language: C - License: BSD-3-Clause - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/virtio-win-kvm-guest-drivers-windows ## Who the source tree is for, and who should take the ISO instead The repository holds KVM/QEMU Windows guest drivers for both paravirtual and emulated hardware. That single sentence covers a wide set of directories: NetKVM for network, viostor and vioscsi for storage, Balloon for memory, viofs, viogpu, vioinput, viorng, vioserial, viosock, pvpanic, ivshmem, pciserial, stdvga, Q35, fwcfg and viocrypt. Each is a separate Windows driver project inside one solution file, virtio-win.sln. The README is direct about the audience. If all you want is to use virtio-win in your Windows virtual machines, it points you at the Fedora virtIO-win documentation for the binaries. The code builds and ships as part of the virtio-win RPM on Fedora and Red Hat Enterprise Linux, and binaries are also published as distribution-neutral ISO and VFD images. So the source repository is not the distribution channel. It is the upstream for people who package, sign or patch the drivers. That distinction matters more here than in most projects. A Windows kernel driver is not something you compile and drop into a guest. The build output is unsigned or test-signed, and the README says plainly that Windows will not load those by default. Anyone arriving from a search for a download is in the wrong place. ## What the build system produces, directory by directory The top level mixes driver sources with packaging and validation scripts. buildAll.bat, build_all_drivers.bat, build_AllNoSdv.bat, build_sdv.bat, build_cab.bat and clean.bat cover the build and packaging path. RunSdv.bat and SDVTOOL.bat drive Static Driver Verifier, which is why the repository carries a build_sdv.bat and a build_AllNoSdv.bat variant: SDV is slow enough that a developer wants a way to skip it. The .ddf files (win10_x64.ddf, win10_x86.ddf, win10_arm64.ddf, win11_x64.ddf, win11_arm64.ddf) are driver package definition files, one per target platform. Their presence tells you the supported Windows targets without needing a support matrix in the README: Windows 10 and Windows 11, x86, x64 and arm64, with no Windows 7 or Windows 8 definition file at the top level. The build/ directory and the .hck-ci/ directory sit alongside, the latter pointing at the Microsoft Hardware Compatibility Kit pipeline. The README does not document the build beyond a link to a wiki page titled Building the drivers using Windows 11 24H2 EWDK. That is a specific constraint worth reading twice: the documented path is an Enterprise Windows Driver Kit on Windows 11 24H2, not a general-purpose cross-compilation setup. There is no CMake or Meson file at the top level, and the solution file is a Visual Studio artifact. If your build environment is not a Windows host with the EWDK installed, the documented path does not apply to you. ## Building from source: what the README gives you and what it does not The README does not contain build steps. It contains a pointer: clone the repository and follow the instructions in Building the Drivers, which links to virtio-win.github.io. The repository root does carry batch files that correspond to stages of that process, so the shape of the workflow is visible even though the commands are not spelled out here. A typical sequence against those scripts looks like this. Each of these files exists at the repository root, and the names are the ones in the tree, not invented flags: ```bash git clone https://github.com/virtio-win/kvm-guest-drivers-windows cd kvm-guest-drivers-windows build_all_drivers.bat ``` For a faster loop that skips Static Driver Verifier, the tree offers the no-SDV variant: ```bash build_AllNoSdv.bat ``` Packaging into a driver cabinet uses build_cab.bat, and clean.bat resets the tree. What you should expect after a successful build is an unsigned or test-signed driver set. The README names the test certificate explicitly: Tools/VirtIOTestCert.cer. Installing a driver signed with that certificate requires test-signing mode in Windows, and the README links Microsoft's page on installing test-signed driver packages rather than restating the procedure. That is the honest boundary of this section. The repository tells you which script to run and what class of signature you get. It does not tell you, in the README, which Windows version each script targets or how to stage the result into a guest image. Those answers live on the wiki, outside this material. ## Signing is the real gate, and it is not a formality Three signing paths appear in the README, and they are not interchangeable. Unsigned or test-signed binaries come out of a plain source build and will not load by default. Cross-signed binaries, the kind that ship in the Fedora RPM, require your own code-signing certificate; the README states they work on all versions of Windows except the latest Windows 10 with secure boot enabled, and that systems with cross-signed drivers will not receive Microsoft support. Microsoft-signed binaries, the kind in the Red Hat Enterprise Linux RPM, require submitting the drivers to Microsoft with test results through the WHQL process. Two conditions attach to the WHQL path and both are easy to miss. First, base your drivers on commit eb2996de or newer, because the README says the GPL licence used before that commit is not compatible with WHQL. Second, change the Hardware IDs so your drivers do not match devices exposed by upstream KVM/QEMU. The README calls this especially important if you plan to distribute through Windows Update and links Microsoft's publishing restrictions. This is the part of the project most likely to surprise a team that assumed a BSD-3-Clause repository means a frictionless redistribution story. The licence on the repository is permissive, but the operating system's driver loading rules are not, and the README treats them as the binding constraint. ## Where virtio-win is the wrong choice If your guest runs on a hypervisor that is not QEMU or KVM, these drivers are not for you. The repository description is explicit: Windows paravirtualized drivers for QEMU/KVM. The devices the drivers bind to are the ones QEMU exposes. On a different hypervisor there is nothing for them to attach to, and the Hardware ID guidance in the README exists precisely because matching upstream QEMU device IDs is a deliberate coupling. A second case: you need a supported, Microsoft-signed driver but you have no way to run the WHQL process. The repository gives you the source and the build scripts, but the README frames WHQL as something you submit and pay for in engineering time, with a set of test results. There is no path in this material from a local build to a fully supported signed driver without that step. A third: you are on Windows 7 or Windows 8. The top-level .ddf files cover Windows 10 and Windows 11 only, in x86, x64 and arm64. Whatever older driver packages circulate, the tree in front of you does not define them. Searches for virtio drivers Windows 7 land outside what this repository's packaging files describe. ## Alternatives, and the difference in approach The realistic alternative is not another driver project. It is the prebuilt binary channel. The README sends you to the Fedora virtIO-win documentation for obtaining the binaries, and the code itself builds and ships as part of the virtio-win RPM on Fedora and Red Hat Enterprise Linux. The difference is not technical quality but provenance and signing: the RPM path gives you binaries that have already been through the signing process the distribution supports, and you do not need a Windows build host, an EWDK install or a code-signing certificate. If you are on RHEL, the README describes the RHEL RPM as carrying Microsoft-signed binaries, fully supported. That is a different artifact from anything you will produce locally, and it is the correct choice for production guests where a driver that fails to load is an outage. The trade-off cuts the other way when you need to change driver behaviour. The RPM and ISO are frozen binaries. If you need a patch, a different Hardware ID, or a build against a specific commit, the source repository is the only route, and you accept the signing work that comes with it. There is no middle option in this material where you get a custom build and someone else's signature. ## Maintenance, release cadence and licence cost The repository is not archived, and the last push was on 2026-09-23. Recent releases are tagged mm324 on 2026-09-14, mm323 on 2026-09-10 and mm322 on 2026-07-22. The cadence in that window is roughly weekly to monthly, which tells you fixes land often, but it also means a fork pinned to an old commit drifts quickly. Upgrade cost depends on which signing path you chose. If you consume the Fedora or RHEL RPM, upgrading is a package operation. If you build and sign your own, every upstream change you want to absorb means a rebuild, a re-sign, and for WHQL drivers a resubmission. The README's instruction to change Hardware IDs compounds this: your fork is deliberately not binary-compatible with upstream device matching, so you cannot mix your signed drivers with upstream ones casually. On licensing, the repository is BSD-3-Clause. The README adds a constraint that is not a licence term but has the same effect on distribution: the GPL licence used prior to commit eb2996de is described as incompatible with WHQL. If you are choosing a base commit for a submission, that date is the floor. This is a factual boundary stated by the project, not legal advice; if the WHQL and licence interaction affects your product, take it to counsel rather than to a README. ## Conclusion Build from this repository only if you need to modify a driver or produce your own signed binaries, and only after confirming you can sign them: drivers built here are unsigned or test-signed with Tools/VirtIOTestCert.cer and Windows will not load them by default. Everyone else should take the binaries from the Fedora virtIO-win documentation instead. Before investing in a WHQL submission, check that your base commit is eb2996de or newer, because the README states the GPL licence used before that commit is not compatible with WHQL. ## FAQ ### What are the latest virtio drivers for Windows? The repository's most recent release tag in this material is mm324, dated 2026-09-14, followed by mm323 on 2026-09-10 and mm322 on 2026-07-22. For the binaries themselves, the README directs users to the Fedora virtIO-win documentation. ### Where do I download virtio-win instead of building it? The README points to the Fedora virtIO-win documentation for obtaining the binaries, and notes that the code builds and ships as part of the virtio-win RPM on Fedora and Red Hat Enterprise Linux. Distribution-neutral ISO and VFD images are also published. ### Can I build virtio-win for Windows 11? The repository ships win11_x64.ddf and win11_arm64.ddf driver package definition files, and the README links a wiki page on building the drivers using the Windows 11 24H2 EWDK. A locally built driver will be unsigned or test-signed and Windows will not load it by default. ### Why will Windows not load the driver I built from this repository? The README states that drivers built from source are either unsigned or test-signed with Tools/VirtIOTestCert.cer, and that Windows will not load them by default. It links Microsoft's documentation on installing test-signed driver packages for the test-signing procedure. ## Sources - [License: BSD-3-Clause](https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/LICENSE) - [Project website](https://www.linux-kvm.org/page/WindowsGuestDrivers) - [README](https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/README.md) - [Releases](https://github.com/virtio-win/kvm-guest-drivers-windows/releases) - [virtio-win/kvm-guest-drivers-windows on GitHub](https://github.com/virtio-win/kvm-guest-drivers-windows) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/virtio-win-kvm-guest-drivers-windows