Sander van Leeuwen wrote: > Daniel P. Berrange wrote: >> While one could in theory change KVM to only activate VMX when a >> guest is >> started this wouldn't give a significant improvement to the user >> experiance. >> Instead of being able to rely on KVM working, it now may or may not >> work depending on whether you happen to have a VirtualBox guest >> running or not & >> vica-verca. You still would not be able to run guests from both >> concurrently >> which should surely be the real goal. The only way I see the latter >> being >> achieved is if VirtualBox were to leverage the existing KVM kernel >> APIs to >> access the underlying hardware virt capabilities. >> > You are mistaken. VT-x allows multiple clients to work concurrently. > There's only one catch: all those > clients should follow certain guidelines.
Currently, kvm assumes that it is the only user that issues vmptrld instructions. There may me other such assumptions in the code. There is also the question of who issues the vmxon/vmxoff instructions and set the magic msr bits that enable kvm. You can't have two hypervisors doing that; that would be racy. It should be possible to abstract those bits out to something outside kvm, but I don't see that happening. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
