kvm-intel: Auto-load on CPUs with VMX.

Enable x86 feature-based autoloading for the kvm-intel module on CPUs with X86_FEATURE_VMX.

---

I've tested this and it works correctly. I can also supply the obvious equivalent patch for kvm-amd on AMD CPUs with SVM, but I don't have any such CPUs to test that on.

 arch/x86/kvm/vmx.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

index 3b4c8d8..bb3bcff 100644
@@ -27,6 +27,7 @@
 #include <linux/highmem.h>
 #include <linux/sched.h>
 #include <linux/moduleparam.h>
+#include <linux/mod_devicetable.h>
 #include <linux/ftrace_event.h>
 #include <linux/slab.h>
 #include <linux/tboot.h>

@@ -51,6 +52,12 @@
 MODULE_AUTHOR("Qumranet");
 MODULE_LICENSE("GPL");
 
+static const struct x86_cpu_id vmx_cpu_id[] = {
+	X86_FEATURE_MATCH(X86_FEATURE_VMX),
+	{}
+};
+MODULE_DEVICE_TABLE(x86cpu, vmx_cpu_id);
+
 static bool __read_mostly enable_vpid = 1;
 module_param_named(vpid, enable_vpid, bool, 0444);
 

1.7.9.1

On the one hand this makes sense and is consistent with how other modules are loaded. On the other hand this will waste memory for non-virt users running on distro kernels (but distro kernels can override this new behaviour anyway).

I'm inclined to apply, but will wait for more comments.

error compiling committee.c: too many arguments to function

Today, we auto-load matching modules for everything we find. It seems still the best compromise for the default behaviour to make things work without special care or knowledge, especially for distribution users.

People who care, can simply 'optimize' that with blacklisting the aliases in the modprobe config. That way stuff does not get auto-loaded, but can still be modprobed manually by the module name.

We used to load these modules with rather broken shell scripts, poking around in /proc/cpuinfo during bootup, anyway. So this standard way of using an alias is by far the better alternative to it, and I'm all for doing that.

For what it's worth:

Thanks,
Kay

Thanks, applied.

error compiling committee.c: too many arguments to function

Enable x86 feature-based autoloading for the kvm-amd module on CPUs with X86_FEATURE_SVM.

---

As promised, the corresponding patch for kvm-amd.

 arch/x86/kvm/svm.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

index e385214..cd95ea7 100644
@@ -22,6 +22,7 @@
 #include "x86.h"
 
 #include <linux/module.h>
+#include <linux/mod_devicetable.h>
 #include <linux/kernel.h>
 #include <linux/vmalloc.h>
 #include <linux/highmem.h>

@@ -42,6 +43,12 @@
 MODULE_AUTHOR("Qumranet");
 MODULE_LICENSE("GPL");
 
+static const struct x86_cpu_id svm_cpu_id[] = {
+	X86_FEATURE_MATCH(X86_FEATURE_SVM),
+	{}
+};
+MODULE_DEVICE_TABLE(x86cpu, svm_cpu_id);
+
 #define IOPM_ALLOC_ORDER 2
 #define MSRPM_ALLOC_ORDER 1
 

It appears to work fine on my amd boxen. The only problem is that I've no idea when it will be possible to finally disable the init script (shipped in Debian and other distros) to load the module based on /proc/cpuinfo contents. It will do nothing on kernels with this (or kvm-intel) change applied, but we still need to support older kernels without that feature... :)

Josh, and I'm sure you will be the first who'll file a bugreport against qemu-kvm in Debian requesting the startup script to be removed!.. ;))

Thanks,

/mjt

Thanks for testing it. Can I interpret that as a Tested-by/Acked-by?

Each stable release of Debian has a specific minimum kernel version that it supports, typically determined by the requirements of packages such as udev. As far as I know, the next stable release will ship with 3.2, and I don't think the necessary infrastructure exists in 3.2 to backport this patch (though I'd love to hear otherwise if it does), so that release will probably need to include the init script. However, the next release should have no problem safely dropping it and requiring a sufficiently new kernel.

In unstable (after the release), qemu-kvm could just go ahead and drop the script with a NEWS.Debian entry telling people to add the necessary module to /etc/modules if they have an older kernel.

I don't know where you could possibly get that idea. ;)

- Josh Triplett

Applied, thanks.