How Intel Virtualisation Works(binarydebt.wordpress.com) |
How Intel Virtualisation Works(binarydebt.wordpress.com) |
He created a memory allocator in which it is impossible to create dangling pointers. He used it by becoming the kernel through Intel VT-x (i.e. he uses ring 0). He uses libdune for this, which in turn uses Intel VT-x.
Check it out at: https://dangless.gaborkozar.me/
I'm going to write an ascii diagram in the upcoming edit. For now: I'll just leave you with the legend that my friend made.
Note: my friend made a video and slides. So for people who are interested, his slides and videos are much nicer to look at than this diagram.
DIAGRAM (of all the physical and virtual memory)
|1|<-A->|2|<-B->|3|<-C->|4|
LEGEND
1 = host physical memory
2 = host virtual memory
3 = guest physical memory
4 = guest virtual memory
A: normal host pagetable
B: embedded page table (this is VT-X thingy)
C: guest page table (this is what I mess with)
For what workload?
https://en.wikipedia.org/wiki/Intel_iAPX_432#Object-oriented...
You might run out of address space eventually, that might be a good moment to drain current workitems and launch new ones into a replacement process. This would work well for things like web services since each request is relatively short lived.
Also, after moving a VMCS from a physical CPU to another you have to do VMLAUNCH the first time your start the guest on the new CPU, because you had VMCLEARed it on the old CPU. That's it. :-)
Intel seems to have accepted this state of affairs. On newer chips, it is much faster to enable and disable virtualization.
We could be talking past each other. Here, to clarify, are 3 methods:
x. The driver never does VMXOFF.
y. The driver does VMXON when asked to run a guest. The driver may handle events from the guest (such as page faults or CPUID emulation) without doing VMXOFF, but the driver will do a VMXOFF prior to letting other host processes and drivers run.
z. The driver does VMXOFF every time the VM exits.
We found that choice x was not normally used. If it were, then VMX drivers would not be able to coexist with each other. I'm not saying that everybody uses choice z. Choice y is probably also popular.
What mainframes have done for years and modern PC VMs do, is type 1 virtualization, whereas stuff like Virtual Box is type 2 virtualization.
You have this reversed: AMD developed x64-64 virt, and Intel decided to go their own way.
Yes, if you look at the way V86 is implemented, it wouldn't be too hard to extend it to full virtualisation --- something like a "VMX mode task" would've been ideal.
Here is the HN entry on it: https://news.ycombinator.com/item?id=18214738
Most VMX drivers are unable to coexist (in the sense that VirtualBox, HAXM, Hyper-V, and VMWare Player are mutually incompatible / can't be used in the same Windows boot session).
It fully disables VMX before turning interrupts back on.
If I remember right, it works fine with VMWare running on the same machine, so they must be doing likewise. I think I recall problems with Hyper-V, so you are probably right about that one. It looks like Hyper-V is the uncooperative VMX driver that refuses to play nice with others.