The KVM example is sort of weird to me: the goal of that code inside KVM is to provide a comparatively "easy" interface for creating VMs on multiple architectur

The KVM example is sort of weird to me: the goal of that code inside KVM is to provide a comparatively "easy" interface for creating VMs on multiple architectures. The code isn't particularly motivating if you don't see how it's used. Until you get pretty deep into the weeds, none of KVM's code can actually do anything architecturally specific, since all of the glue code is architecturally agnostic. KVM supports a ton of architectures, intel-x86/amd-x86/armv/s390/risc-v/... On top of that, KVM tries to avoid having extra ioctls (essentially KVM syscalls). A lot of the ioctls are so flexible that they don't really tell you anything about what a CPU should* look like. The ioctls let you create a VM that is in essentially any valid state a CPU could reach (since VMs need to be migratable). Take a look at the sample code in the rust kvm-ioctls crate [1] and you'll see what defines a VM. 1) Open the KVM fd for access to the ioctls. 2) Make the VM fd. 3) Make guest RAM, and shove the asm from up above into it. 4) Make a vCPU. 5) Initialize the registers for the vCPU. 6) Run the VM, and handle the exits (KVM sometimes can't handle what the VM is doing and returns to usermode to have them deal with it. Think device emulation). This avoids initializing a lot of state for the VM, but it's enough to run it. Notable details are things like CPUID (supported cpu features for the VM), the Interrupt Descriptor Table, and the control registers. If this VM took an exception/interrupt right now, it would immediately triple fault. This sample VM is running in "real mode" (16-bit unpaged mode). [1] https://github.com/rust-vmm/kvm-ioctls/blob/master/src/lib.rs https://github.com/rust-vmm/kvm-ioctls/blob/master/src/lib.r...