| Message ID | 20240608000639.3295768-9-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: Register cpuhp/syscore callbacks when enabling virt | expand |
On 6/8/24 02:06, Sean Christopherson wrote: > Enable virtualization when KVM loads by default, as doing so avoids the > potential runtime overhead associated with using the cpuhp framework to > enabling virtualization on each CPU. Hah, should have read ahead to this point of the series. Just squash this in the earlier patch and call it a day; and place all the worrisome remarks about possible latency along with documentation for the parameter. Oops, there's no documentation, :) please add it to Documentation/admin-guide/kernel-parameters.txt in v2. Thanks, Paolo > Prior to commit 10474ae8945c ("KVM: Activate Virtualization On Demand"), > KVM _unconditionally_ enabled virtualization during load, i.e. there's no > fundamental reason KVM needs to dynamically toggle virtualization. These > days, the only known argument for not enabling virtualization is to allow > KVM to be autoloaded without blocking other out-of-tree hypervisors, and > such use cases can simply change the module param, e.g. via command line. > > Note, the aforementioned commit also mentioned that enabling SVM (AMD's > virtualization extensions) can result in "using invalid TLB entries". > It's not clear whether the changelog was referring to a KVM bug, a CPU > bug, or something else entirely. Regardless, leaving virtualization off > by default is not a robust "fix", as any protection provided is lost the > instant userspace creates the first VM. > > Suggested-by: Chao Gao <chao.gao@intel.com> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > virt/kvm/kvm_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index e20189a89a64..1440c0a7c3c3 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -5495,7 +5495,7 @@ static struct miscdevice kvm_dev = { > }; > > #ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING > -static bool enable_virt_at_load; > +static bool enable_virt_at_load = true; > module_param(enable_virt_at_load, bool, 0444); > > __visible bool kvm_rebooting;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e20189a89a64..1440c0a7c3c3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5495,7 +5495,7 @@ static struct miscdevice kvm_dev = { }; #ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING -static bool enable_virt_at_load; +static bool enable_virt_at_load = true; module_param(enable_virt_at_load, bool, 0444); __visible bool kvm_rebooting;
Enable virtualization when KVM loads by default, as doing so avoids the potential runtime overhead associated with using the cpuhp framework to enabling virtualization on each CPU. Prior to commit 10474ae8945c ("KVM: Activate Virtualization On Demand"), KVM _unconditionally_ enabled virtualization during load, i.e. there's no fundamental reason KVM needs to dynamically toggle virtualization. These days, the only known argument for not enabling virtualization is to allow KVM to be autoloaded without blocking other out-of-tree hypervisors, and such use cases can simply change the module param, e.g. via command line. Note, the aforementioned commit also mentioned that enabling SVM (AMD's virtualization extensions) can result in "using invalid TLB entries". It's not clear whether the changelog was referring to a KVM bug, a CPU bug, or something else entirely. Regardless, leaving virtualization off by default is not a robust "fix", as any protection provided is lost the instant userspace creates the first VM. Suggested-by: Chao Gao <chao.gao@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> --- virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)