On 06/13/2010 03:23 PM, Nadav Har'El wrote:
The SVM module had a "nested" option, on by default, which controls whether to allow nested virtualization. Now that VMX also supports nested virtualization, we can move this option to x86.c, for both SVM and VMX. The "nested" option takes three possible values. 0 disables nested virtualization on both SVM and VMX, and 1 enables it on both. The value 2, which is the default when this module option is not explicitly set, asks each of SVM or VMX to choose its own default; Currently, VMX disables nested virtualization in this case, while SVM leaves it enabled. When nested VMX becomes more mature, this default should probably be changed to enable nested virtualization on both architectures. --- .before/arch/x86/kvm/x86.c 2010-06-13 15:01:28.000000000 +0300 +++ .after/arch/x86/kvm/x86.c 2010-06-13 15:01:28.000000000 +0300 @@ -95,6 +95,17 @@ EXPORT_SYMBOL_GPL(kvm_x86_ops); int ignore_msrs = 0; module_param_named(ignore_msrs, ignore_msrs, bool, S_IRUGO | S_IWUSR); +/* If nested=1, nested virtualization is supported. I.e., the guest may use + * VMX or SVM (as appropriate) and be a hypervisor for its own guests. + * If nested=0, nested virtualization is not supported. + * When nested starts as 2 (which is the default), it is later modified by the + * specific module used (VMX or SVM). Currently, nested will be left enabled + * on SVM, but reset to 0 on VMX. + */ +int nested = 2; +EXPORT_SYMBOL_GPL(nested); +module_param(nested, int, S_IRUGO); +
A global variable names 'nested' is not a good idea. I recommend having a kvm-intel scope module parameter instead, that also avoids the 0/1/2 values.
After the patches are merged we can try to consolidate here. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
