In our previous article, we unveiled another future feature of Nitrux, VMetal.
VMetal is not a wrapper or a compatibility layer; it makes use of QEMU and KVM (Kernel-based Virtual Machine) on the software side and of VFIO and IOMMU on the hardware side, meaning that Windows is accessing directly the hardware that it utilizes.
With VMetal, we hope to bring our users the ability to run Windows software to their Nitrux systems. For more details on what is VMetal, check the article above.
How to check the compatibility?
For this feature in Nitrux to work, the hardware where VMetal will be running must support specific features; otherwise, the software will not work, and you won’t be able to enjoy the benefits.
So in this article, let’s dive into what you will need to run VMetal. First, let’s check the file at /proc/cpuinfo, this file has information about your CPU. The report includes the number of CPUs, threads, cores, sockets, and Non-Uniform Memory Access (NUMA) nodes.
The command lscpu is particularly useful for this purpose. From the image below, we can extract these bits of information.
Check if the CPU supports 64-bits
- lm — If you see lm flag means you’ve 64 bit Intel or AMD CPU.
Does the CPU have virtualization capabilities?
- vmx — Intel VT-x.
- svm — AMD SVM.
These flags indicate that the CPU supports virtualization.
Additional Intel CPU flags
- ept — Intel extended page table support enabled to make emulation of guest page tables faster.
- vpid — Intel virtual processor ID. Make expensive TLB flushes unnecessary when context switching between guests.
- tpr_shadow and flexpriority — Intel feature that reduces calls into the hypervisor when accessing the Task Priority Register, which helps when running certain types of SMP guests.
- vnmi — Intel Virtual NMI assists with selected interrupt events in guests.
Additional AMD CPU flags
- npt — AMD Nested Page Tables, similar to Intel EPT.
- lbrv — AMD LBR Virtualization support.
- svm_lock — AMD SVM locking MSR.
- nrip_save — AMD SVM next_rip save.
- tsc_scale — AMD TSC scaling support.
- vmcb_clean — AMD VMCB clean bits support.
- flushbyasid — AMD flush-by-ASID support.
- decodeassists — AMD Decode Assists support.
- pausefilter — AMD filtered pause intercept.
- pfthreshold — AMD pause filter threshold.
Check if the motherboard supports EFI or UEFI
To check the support for the Extensible Firmware Interface or the Unified Extensible Firmware Interface, you can use the following command.
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
Check for UEFI support of the graphics card
Checking this is more difficult to verify since this information is only available by dumping the ROM of the GPU and parsing it. However, it’d be safe to say that if the operating system has booted with UEFI; thus, the graphics card supports it.
Indeed, a good and easy way to check this is to visit the TechPowerUp VGA BIOS Collection and search for your graphics card.
To understand this, let’s give some background information.
- UGA vs. GOP — There are two EFI video systems, UGA and GOP. The latter was introduced with EFI 2.x (aka UEFI); all UEFI-based systems use GOP. In principle, all EFI 1.x systems should use UGA; however, Apple (which still uses EFI 1.x, even in its most recent products) has ported UGA to its EFI, so some (but not all) Macs have EFI 1.x with GOP. There may be other exceptions. This distinction is essential at the firmware level, but not really at the OS level.
But what are UGA and GOP? You may ask, here’s how The Unified Extensible Firmware Interface Forum describes both.
GOP — The Graphics Output Protocol (GOP) is enabled by the UEFI driver to support graphic console output in the pre-OS phase. The ultimate goal of GOP is to replace legacy VGA BIOS and eliminate VGA HW functionality. The GOP driver is a replacement for legacy video BIOS and enables the use of UEFI pre-boot firmware without CSM. The GOP driver can be 32-bit, 64-bit, or IA-64 with no binary compatibility. UEFI pre-boot firmware architecture (32-/64-bit) must match the GOP driver architecture (32-/64-bit).
Some advantages of using GOP:
1. Easier portability and fewer resource constraints.
2. All GPUs within a platform become “equal”; no more unique “VGA enabled” GPU.
3. No more messy and hard-to-maintain proprietary INT15 handshaking between platform and GPU.
Here is a quick comparison between GOP and video BIOS:
- GOP: No 64 KB limit. 32-bit protected mode. No need for CSM. Speed optimized (fast boot). The UEFI pre-boot firmware architecture (32-/64-bit) must match the GOP driver.
- Video BIOS: 64 KB limit. 16-bit execution. CSM is needed with UEFI system firmware. Performance is inferior to GOP CSM. The VBIOS works with both 32- and 64-bit architectures.
UGA — Universal Graphics Adapter (UGA) is a hardware-independent design that encapsulates and abstracts low-level graphics hardware in a conventional manner through firmware. UGA is a firmware standard, intended to wrap existing or planned hardware, including VGA. UGA does not require the use of real-mode assembly language, a direct hardware register, or frame buffer access to a program, thus providing advantages over conventional systems. UGA supports basic drawing operations, continuous display modes, and power management. As a firmware-based standard, UGA facilitates updating a system to support both evolving and new hardware features.
UGA features include, but are not limited to:
- Hardware details being wrapped by firmware;
- Exposed device capabilities being implemented in firmware;
- Native mode support being exposed by firmware; not requiring access to the legacy I/O ports or memory;
- Employing Base Address Registers (BARs) in PCI (Peripheral Component Interconnect, a local bus standard) space only; not requiring real-mode execution environment;
- Not limiting the size of BIOS to 64K; facilitating adding new functionality to the BIOS; cross-platform support (e.g., x86, Itanium);
- Improved overall graphics hardware and driver quality, and being able to code a BIOS in a higher-level language (e.g., C vs. assembler/machine).
In this document by Intel, it is described that a VBIOS and GOP firmware can’t coexist on the same platform, citing that “This is not recommended as the UEFI pre-boot firmware will choose the graphics firmware component for console_out during runtime based on an algorithm (currently the version number). The graphics firmware component with the highest version number will be chosen, and this algorithm is subject to change. This same answer applies to multiple instances of the GOP driver.”
Compatible hardware list
During our research, we narrowed down the minimum hardware required that would meet the requirements described above.
CPU (support for VT-d or AMD-V)
- Intel — Processors that conform to the Sandy Bridge-E, Ivy Bridge-E, Skylake microarchitecture, and newer meet the requirements. For more information, check Intel ARK.
- AMD — Processors that conform to the Bulldozer microarchitecture and newer meet the requirements.
Motherboard chipsets (support for UEFI and IOMMU; VT-d, AMD-V)
- Intel — Chipsets such as X79, X99, all consumer LGA 1151 parts, and newer meet the requirements. For more information, check Intel ARK.
- AMD — Chipsets such as 890FX, 970, 990X, 990FX, and newer meet the requirements.
Support for VT-d requires that both the CPU and motherboard support VT-d, and as such even though Intel’s Ivy Bridge processors support the VT-d extension, the accompanying high-performance chipsets such as Z87 or Z97 do not support VT-d, that is also the case with Broadwell and Haswell processors where the CPUs support VT-d, but the chipsets don’t.
Graphics cards (support for UEFI boot)
- Nvidia — Graphics cards such as some models of the GTX 600 series have support for UEFI, most models from the GTX and GT 700 series and newer fully-support UEFI.
- AMD — Graphics cards such as most models from the Radeon Rx 200 series and newer fully-support UEFI.
To put it simply, and bluntly — perhaps — UEFI is more modern and allows many more things than the Legacy BIOS ever did, it’s a matter of progression.
Of course, that good old Core 2 Quad or Phenom II-era computer is still perfectly usable today, but it lacks many new characteristics that make it impossible for features such as VMetal that depend on hardware support to work in the first place.
Therefore I want to reiterate the following.
We build Nitrux for the present and the future, not for the past.
The extent to which hardware we support spans approximately 10 years into the past, but it will span many more years into the future because that’s where we are moving, forward.