One thing I find annoying about x86 virtualisation is that it already has a mode called V86, introduced in the 386, but instead of extending that with more functionality, they introduced yet another set of instructions, and of course AMD also has its own completely incompatible way to do virtualisation. The nice thing about V86 is it integrates well with the existing task-segment model.
How Intel Virtualisation Works
21–30 of 32 posts
Re: How Intel Virtualisation Works
#22One thing I find annoying about x86 virtualisation is that it already has a mode called V86, introduced in the 386, but instead of extending that with more functionality, they introduced yet another set of instructions, and of course AMD also has its own completely incompatible way to do virtualisation. The nice thing about V86 is it integrates well with the existing task-segment model.
> AMD also has its own completely incompatible way to do virtualisation.
You have this reversed: AMD developed x64-64 virt, and Intel decided to go their own way.
Re: How Intel Virtualisation Works
#23One thing I find annoying about x86 virtualisation is that it already has a mode called V86, introduced in the 386, but instead of extending that with more functionality, they introduced yet another set of instructions, and of course AMD also has its own completely incompatible way to do virtualisation. The nice thing about V86 is it integrates well with the existing task-segment model.
hi userbinator :) isn't the purpose of virtual 8086 mode somewhat different? i.e. to run real mode applications while the cpu is in protected mode? or did you mean that virtual 8086 could be generalised into a wider virtualisation system?
Re: How Intel Virtualisation Works
#24Earlier quoted context omitted.
This is probably interesting enough for its own post.
Done! You can see it here: https://dangless.gaborkozar.me/
Edit: I was on my phone that is just his normal website that I linked to earlier.
Here is the HN entry on it: https://news.ycombinator.com/item?id=18214738
Re: How Intel Virtualisation Works
#25Since Intel chips are really RISC underneath the hood, I wonder what crazy x86 emulation hoops they have to jump through already.
Re: How Intel Virtualisation Works
#26Earlier quoted context omitted.
No, this is not true. KVM always keeps VMX on, Xen too even when running paravirtualized guests, Hyper-V does not even have a concept of "the VM not running code". Maybe VMware Workstation and VirtualBox?
Well, I'm part of a team that maintains a VMX driver, and we've looked at what the competition did. It's been a while since we did that, so change is possible. Hyper-V might be special. 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 emula…
> If it were, then VMX drivers would not be able to coexist with each other.
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).
Re: How Intel Virtualisation Works
#27Earlier quoted context omitted.
Well, I'm part of a team that maintains a VMX driver, and we've looked at what the competition did. It's been a while since we did that, so change is possible. Hyper-V might be special. 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 emula…
> If it were, then VMX drivers would not be able to coexist with each other. 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).
I just checked a proprietary VMX driver.
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.
Re: How Intel Virtualisation Works
#28I haven't read this article yet, but this is more or less the best moment to showcase you guys what a friend of mine made. I think it's really cool. 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…
One could alternatively never reuse addresses and decommit pages once the last object on a page is gone. No need for VT.
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.
Re: How Intel Virtualisation Works
#29One thing I find annoying about x86 virtualisation is that it already has a mode called V86, introduced in the 386, but instead of extending that with more functionality, they introduced yet another set of instructions, and of course AMD also has its own completely incompatible way to do virtualisation. The nice thing about V86 is it integrates well with the existing task-segment model.
hi userbinator :) isn't the purpose of virtual 8086 mode somewhat different? i.e. to run real mode applications while the cpu is in protected mode? or did you mean that virtual 8086 could be generalised into a wider virtualisation system?
or did you mean at virtual 8086 could be generalised into a wider virtualisation system?
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.
Re: How Intel Virtualisation Works
#30One thing I find annoying about x86 virtualisation is that it already has a mode called V86, introduced in the 386, but instead of extending that with more functionality, they introduced yet another set of instructions, and of course AMD also has its own completely incompatible way to do virtualisation. The nice thing about V86 is it integrates well with the existing task-segment model.
> AMD also has its own completely incompatible way to do virtualisation. You have this reversed: AMD developed x64-64 virt, and Intel decided to go their own way.
But VT-x was released November 2005 and AMD-V released May 2006?