On 04.11.2008, at 11:36, Avi Kivity wrote:
Alexander Graf wrote:
This patch moves the actual VMX enablement from the initialization
of the module to the creation of a VCPU.
With this approach, KVM can be easily autoloaded and does not block
other VMMs while being modprobe'd.
This improves the user experience a lot, since now other VMMs can
run, even though KVM is loaded, so users do not have to manually
load/unload KVM or any other VMM module.
Compared to the previously suggested approach "2", which would
introduce a complete framework that brings almost no benefit,
this approach enables coexistence of multiple VMMs without much
intervention. Thanks to Gerd for pointing that out.
I verified that this approach works with VirtualBox.
This should be done in x86.c and made to apply to svm as well.
Other VMMs would use efer.svme as an indication that svm is in use,
similar to cr4.vmxe today.
Right, that sounds good. So just track the usage counter in x86.c and
then split the hardware_{en,dis}able functions? Or do you want to
actually call hardware_{en,dis}able on the usage counter events? There
is no real need to enable/disable everything just because of the usage
counter.
I'm not thrilled about this (it could be done, much more simply, by
having the other hypervisor rmmod kvm), but okay.
It's not that I'm thrilled either, but it seriously annoys me to block
others for "no reason". And having all other hypervisors support kvm
module unloading just because doesn't sound right. Plus, this approach
is unprivileged user safe. A user that has access to /dev/vbox (or
whatever it's called) and /dev/kvm can still use both hypervisors
without the need for root access.
Alex
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
