Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
No VT? No fair to *any* of the platforms reviewed.No VT? No fair to *any* of the platforms reviewed.Posted Feb 14, 2008 4:06 UTC (Thu) by xoddam (subscriber, #2322)In reply to: No VT? No fair to *any* of the platforms reviewed. by walken Parent article: Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)
> current VT hardware is slower than the emulation techniques we can do in software. I'm intrigued (though not *quite* incredulous). ... I suppose that's not the sort of comment your employer would encourage you to elaborate upon in a public forum, though? I would have thought the best you could do in a generic way would be to trap, though I suppose numerous specific performance optimisations are applicable if you're intimate with your various guest OSes.
(Log in to post comments)
No VT? No fair to *any* of the platforms reviewed. Posted Feb 14, 2008 8:37 UTC (Thu) by walken (subscriber, #7089) [Link] Well I can't tell *all* about the secret sauce but the main ingredients are already known... See http://portal.acm.org/citation.cfm?id=1168857.1168860 for example for a relevant published paper. VMware can use binary translation - a technique that is actually quite similar to what qemu or many java JIT environments are doing. It's complex but surprisingly inexpensive if you do it right. Since we don't directly execute the guest kernel code but rather a translation of it, we have an amount of flexibility not available in hardware - if we find out that our translation for something traps too much, we can look at it and figure out an alternative translation that will trap less. The first generation VT hardware, on the other hand, is actually quite limited, it provides all the traps you need to write a trap-based virtualization monitor, but in the end you still have to handle all these traps. Most notably the page table virtualization is left out as an exercise to the monitor implementor - this ends up being a lot of traps and with not much one can do about them other than waiting for future generations of VT hardware. Don't get me wrong though, hardware virtualization *will* get faster eventually... it just takes a while though, due to cpu design cycles being longer than software design cycles :)
|
|
||||||||||