While the “Qubes 1.0” branch iscurrently in the final development and testing, we have alreadystarted working on the Next Big Feature, which is a support for HVMdomains (hardware, or VT-x virtualized domains). This allows to rune.g. Windows VMs under Qubes. You might be wondering what so specialabout this, if Xen has been supporting HVM domains, and specificallyWindows VMs for a long time, and Qubes uses Xen hypervisor, so whyhaven't we had Windows support since day one?
The are a couple of things that wedon't like about HVM support in Xen (and also in other VMMs), whichinclude: the need to run device emulator (AKA qemu) in Dom0, the needto use crappy VNC, or a similar protocol to access the VM'sframebuffer, or alternatively, the crazy idea (from security point ofview, that is) of using a pass-through graphics for a VM, the lack ofsupport for disaggregated architecture where backends, e.g. networkbackends, run in other domains than Dom0. In fact even the Xen“stubdomain” feature, introduced a few years ago, that wassupposed to be a solution allowing to move the qemu out of Dom0, inpractice turned out to be quite disappointing, as the qemu in thestub domain still requires an accompanying process of another qemu inDom0, somehow negating all the security benefits this architecture issupposed to bring... And not to mention the omni present assumptionthat backends run always in Dom0, hardcoded in a few places in thestubdomain code.
So, we didn't like it and that's whyQubes had no Windows support for long time. But this has now changed,as we have just finished the 1st stage implementation ofHVM support in Qubes, the way we like it, without any securitycompromises. In our implementation we've completely eliminated allthe qemu remains from Dom0 (it's running in a micro stub domain), thegraphics virtualization fully integrates with our very slim GUIdaemon (we didn't have to modify our GUI daemon at all!), using ourXen-optimized, zero-copy, minimalist GUI protocol, and the networking isalso fully integrated with the Qubes diaggregated networkingarchitecturethat uses isolated domains for all the networking stacks and drivers.Of course, there are still some rough edges, such as no clipboardsupport, and the virtualization is currently in a “per-desktop”mode, rather than in a “per-window” mode, which is used for PVdomains. But, rest assured, we are working on those things rightnow...
This code is currently not public, andthe plan is to release it only after Qubes 1.0 release, either as anupgrade, or as Qubes 2.0. All the dom0 code for HVM support willlikely remain GPL, while any Windows-specific code (agent code) willlikely be proprietary.