Sander van Leeuwen wrote: > Avi Kivity wrote: >> Sander van Leeuwen wrote: >> >>> 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. >> >> > VirtualBox currently always executes vmxon when it wants to execute > some guest code. When leaving > ring 0 it issues the corresponding vmxoff. While that may increase > world switch overhead, it has not turned > out to be an issue for us.
The overhead will increase with newer hardware, as more state is cached on-chip. It's probably okay when deploying to a desktop but i don't think it is good enough for a server. > I think it's a bit risky to use somebody else's vmxon pointer. > > You have a point with the msr updates though. I think the easiest way forward is for you to unload kvm-intel (or kvm-amd) when you load, and to reload it when you unload. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
