NoirVisor: an AMD64 hypervisor written in C with experimental nested virtualization

A VMM that picks its core by reading the CPU vendor

NoirVisor is introduced as the Grimoire hypervisor solution for AMD64 processors, and more fully as a hardware-accelerated hypervisor, or VMM, with support for complex functions and purposes. The target is x86 with hardware virtualisation: Intel processors with VT-x or AMD processors with AMD-V. The mechanism that shapes the whole project is a runtime decision. By design, NoirVisor determines the processor manufacturer and selects the function core, so the same codebase serves both instruction sets, with a VT core and an SVM core in the source tree. That is a different philosophy from a hypervisor that only supports one vendor and refuses to boot on the other, and it is the reason the repository carries per-vendor documentation. The project is written in C and assembly, and the README states that this is because it is procedure-oriented in design. The name comes from Grimoire Noir in NieR:Gestalt/Replicant.

Which processors qualify, including the less obvious ones

The processor requirement section is unusually thorough, and it is worth reading before you assume your CPU is out of scope. Intel processors need Intel 64 and IA-32 architecture support with Intel VT-x, where Intel EPT is preferred but not required. AMD processors need AMD64 architecture with AMD-V, where nested paging is preferred but not required. Beyond the two main vendors, the README records that x86 processors produced by VIA, Zhaoxin and Hygon have hardware-accelerated virtualisation, with the observed facts laid out individually: Intel parts may support Intel VT-x, AMD parts may support AMD-V, VIA parts may support Intel VT-x, Zhaoxin parts may support Intel VT-x and Hygon parts may support AMD-V. The note that early Zhaoxin and VIA parts use Centaur as the vendor is the kind of detail that saves a day of debugging, because CPUID leaves are vendor-specific. The README also says other x86 processors may be supported in future, which is an open door rather than a claim.

Nested virtualization: one path debugging, one absent

The nested virtualization support is the headline feature and the most honest part of the README. The algorithms are documented in readme files in both the VT core and the SVM core directories, and both are labelled as an incomplete version. The current state is stated plainly: nested AMD-V is in the debugging stage, and NoirVisor can run a modified version of SimpleSvm as a nested hypervisor with NPT turned off. Nested Intel VT-x is not supported yet. That asymmetry is worth internalising before planning any experiment, because the two paths are not at the same maturity and the Intel one is further away. The mode you can actually use today is the AMD path, with nested paging disabled and a modified SimpleSvm as the guest hypervisor, which tells you the shape of the current work: getting the outer VMM to expose virtualisation to a guest that itself virtualises.

Building on Windows, where the batch file is not optional

The build section says that using batch is essential, and that the build_prep.bat script should be executed to make directories for a first time compilation. Once NoirVisor is updated, it is recommended to run cleanup.bat before building, and when you use the terminal you can add the /s option to bypass the pause command.

cd build
.\compchk_win7x64.bat /s

The presence of a Python script in the repository root, named make.py, and a build.json at the top level suggest that the batch scripts are being replaced or driven by a script layer, and the repository description says remastering with Rust is in progress, with a rust-dev branch that already exists at GitHub. The README asks contributors who switch branches to run the cleanup.bat script to clean up compiler outputs, which is the same hygiene rule as for the main branch. The contribution guidance is unusually strict in one respect: it says in bold that you must not provide code with C++ which involves the NoirVisor core in your pull request, because the core is written in C and assembly for procedural reasons.

The Windows kernel driver needs a specific WDK ISO

Building the Windows kernel-mode driver has its own chain of dependencies, and the README is specific about versions. You need to download and mount the Enterprise Windows Driver Kit 11 ISO file, with Visual Studio Build Tools 16.11.10 or 17.8.6, onto the T: and V: drives, and it recommends WinCDEmu for mounting the ISO on system startup as a free virtual drive, while noting that if you use it you can specify the drive letter during startup, and that otherwise you may have to mount the ISO manually each time. Two download links are given from Microsoft, one for the 2020 licence with Build Tools 16.11.10 and one for the 2022 licence with 17.8.6, with a warning to get the correct version because you might otherwise fail to compile the latest code. There is a further note that EWDK11 with Visual Studio Build Tools newer than 16 has removed the import library for Windows 7, which is the kind of detail that explains a mysterious link error. Presets for Free and Release builds exist, and the Free build binary does not come with a digital signature, so you would have to sign it yourself.

UEFI runtime drivers need a separate application

The EFI side exists because of a firmware limitation the README spells out: because of different EFI firmware implementations, most modern computer firmware does not support booting an EFI runtime driver directly, so it is necessary to build a separate EFI application. Modern firmware boots the application, and the application loads the runtime driver into memory. The build needs NASM and TianoCore EDK II, with the EDK II source downloaded and extracted to a path named C:\UefiDKII, the EWDK11 ISO with Build Tools 17.8.6 mounted to the V: drive, and NASM's directory added to the PATH environment variable. NoirVisor also uses EDK II libraries, but they must be pre-compiled, and the README points to a separate EDK-II-Library repository for that.

Zydis, recursive clones, and a Python toolchain

The disassembler is Zydis, which you must pre-compile as a static library. Zydis is included as a submodule, and since Zydis itself has a submodule, the README insists that you clone the repository recursively. The Python script section is cut off in the README, but it states that since January 2024 NoirVisor can be built in this way, and the top level entries show a make.py script, a build.json configuration, a build/ directory, a doc/ directory and a src/ tree, along with contributing.md, security.md and a code of conduct file. The MIT licence applies. The topics list the security surface plainly, with amd-v, iommu, nested-virtualization, uefi, vt-d and vt-x, so the project is a security research platform as much as a hypervisor.

Where NoirVisor is the wrong choice

The limits are explicit enough to state. This is not a hypervisor to run production workloads on, and the nested virtualization story is the reason, since a project whose headline capability works on one vendor and not the other is a research platform rather than a platform. It targets x86 only, with no ARM support mentioned, so on Apple silicon or an ARM server it is not an option at all. It is also a C and assembly codebase with a strict contribution rule against C++ in the core, which is a barrier to contributors coming from a modern systems language, partially offset by the Rust branch that is intended to change that eventually. The build environment is Windows-first and batch-driven, with a specific WDK ISO requirement that is awkward in a CI setup. The alternative worth naming is a production hypervisor such as KVM on Linux, which has a real nested virtualization story and a far more forgiving contribution process, or an open research hypervisor in a language with a modern toolchain. NoirVisor earns its place when the point is to read and modify the virtualization code itself, and that is a narrower question than whether you can run workloads on it.

Editorial conclusion

Adopt NoirVisor if you are doing hypervisor research on x86 and need a small, readable VMM written in C and assembly, with a per-vendor core you can read and modify. Do not adopt it expecting production nested virtualization, because the AMD-V nesting path is still in debugging and the Intel VT-x path is not supported at all. Verify first which processor you target and whether the specific feature you need, EPT, nested paging or an IOMMU, is in the scope of the core you plan to use.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Zero-Tang/NoirVisor on GitHub