I've always wondered though how it works with KVM: I know KVM is a virtualisation accelerator that enables passing through native code to the CPU somehow; but it feels like QEMU/KVM basically runs the internet now. Almost the entire modern cloud is built on QEMU and KVM as a hypervisor (right?) but I feel like I'm missing a lot about how it's working.
I also wonder if this steals huge amounts of resources away from emulation, or does it end up helping out. Because to say the modern internet is largely running on QEMU is likely a massive understatement.
https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.... http://www.haifux.org/lectures/312/High-Level%20Introduction... https://zserge.com/posts/kvm/
My rough understanding is that it's the user-space emulation part of a virtualization solution. I.e., when the kernel traps the virtualized process, saying 'nope, you can't do that here', the control falls back to user space handler in QEMU saying, 'hey, the kernel said I can't do that there; can you sort this out?'. And this back-and-forth games keeps happening during the lifetime of the virtualized process.
* An abstraction over second level page tables to map some of a host user process as what the guest thinks of as physical memory.
* An abstraction to jump into the context that uses those page tables, and traps back out in the case of anything that the hardware would normally handle, but the hypervisor wants to handle manually instead.
* A collection of mechanisms to handle some of those traps in kernel space to avoid having to context switch back out to the host user process if the kind of trap is common enough, both in the sense of the trap itself happens often enough to show up on perf graphs, as well as the abstraction being exercised is relatively standard (think interrupt controllers and timers).
Let me know if you have any other questions.
I can vouch for this. I'm no virtualization expert but I did stumble upon some intel developers manuals (truthfully, i fell into the rabbit hole) and just skimming it made everything make much more sense.
For example: https://www.intel.com/content/dam/www/public/us/en/documents... - "CHAPTER 23 INTRODUCTION TO VIRTUAL MACHINE EXTENSIONS"
The link above explains how the VMX extension work on intel processors. Any software doing hardware-assisted virtualization (so no binary translation, no full-system-emulation) will likely be using those instructions.
Any VM is just a `quickget ubuntu 24.04` and `quickemu --vm ubuntu-24.04.conf` away. The conf file is just a yaml that is very readable and can give you more cores/ram/disk easily. Just run `quickget` to get a list of OS's to download.
Other people have given some more comprehensive explanations, but I'll try to put it as simply as possible.
Plain QEMU has a CPU emulation layer called TCG. The machine basically consists of memory (RAM and MMIO devices) and CPUs (CPU registers and state). When QEMU has set up the machine and is ready to run, it calls TCG to say "given this memory and this initial CPU register state, start running instructions". When you use QEMU with KVM, the TCG emulation layer is swapped out with KVM and it asks KVM to start running instructions. That's it. KVM exposes APIs that caller can specify guest memory and initial CPU register state, and a call to run that CPU with that memory.
Going a bit further, the hardware virtualization functions that KVM uses have the ability to map that memory with a second level of translation which lets KVM present it to the guest at the locations it expects, and to prevent the guest from accessing any memory that it should not. The hardware also has the ability to run the CPU in a mode where it has the normal set of registers (which is what QEMU wants), but it maintains some additional hypervisor control registers not available to the guest, and those can ensure the guest can't take complete control of the CPU (for example, the guest OS can "disable interrupts" with the usual MSR or similar bit and that does prevent the guest from getting interrupts, but that it does not disable hypervisor directed interrupts, so the hypervisor can always take back control of the CPU with a hypervisor-IPI or hypervisor timer interrupt).
Further still: when running in plain QEMU mode, devices are emulated by registering MMIO ranges in the memory address space and emulated loads and stores have code to detect these regions and instead of performing a simple load or store, they call into device model code which handles it accordingly. When you plug KVM in, you can still use these emulated devices. These are modeled by using that second level page table to put "not-valid" mappings in those MMIO ranges. These cause the CPU to trigger a page fault when it tries to access them, and KVM sees this, looks up the table of memory registered by QEMU, and sees that it is an address which QEMU wants to handle, so it returns from the KVM_RUN system call with result code that indicates there was an MMIO read/write that needs to be handled. QEMU then directs this into its emulated device model. Then when QEMU has performed that device emulation, it calls back into KVM to continue running the CPU.
It's all pretty clever. The really astounding thing is that most of the basic concepts for all this stuff were developed/discovered/invented like 50+ years ago.
Neat. This will unlock various online "playgrounds" for a number of CPU architectures, among other interesting use cases.
Likely this was possible beforehand, but it's nice to see it added as a feature to the project directly.
It's not possible to run an android VM on QEMU right? As in, is it officially supported? (I know about Waydroid)
https://www.fosshub.com/Android-x86.html
They don't seem to be well supported anymore, and there aren't many prebuilt alternatives. One can always compile AOSP from source, though Google does not make this easy.
Havoc•2h ago
>(Cannot access the database)
_joel•2h ago