KVM: SVM: Allow EFER.LMSLE to be set with nested svm
in [Kernel]
|
Prev: [PATCH 2/4] perf/record: simplify TRACE_INFO tracepoint check
Next: KVM: SVM: Allow EFER.LMSLE to be set with nested svm
From: Avi Kivity on 5 May 2010 10:50 On 05/05/2010 05:04 PM, Joerg Roedel wrote: > This patch enables setting of efer bit 13 which is allowed > in all SVM capable processors. This is necessary for the > SLES11 version of Xen 4.0 to boot with nested svm. > Interesting, why does it require it? Obviously it isn't needed since it manages to run on Intel without it. > /* Intel MSRs. Some also available on other CPUs */ > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index 74f7b9d..bc087c7 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -610,7 +610,7 @@ static __init int svm_hardware_setup(void) > > if (nested) { > printk(KERN_INFO "kvm: Nested Virtualization enabled\n"); > - kvm_enable_efer_bits(EFER_SVME); > + kvm_enable_efer_bits(EFER_SVME | EFER_LMSLE); > } > > for_each_possible_cpu(cpu) { > What if the host doesn't have it? Why enable it only for the nested case? It's not svm specific (it's useful for running non-hvm Xen in non-nested mode). Isn't there a cpuid bit for it? If so, it should be exposed to userspace, and the feature should depend on it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 5 May 2010 11:10 On 05/05/2010 06:04 PM, Joerg Roedel wrote: > Because there is no cpuid bit for this feature. That is sad. > You can roughly check > for it using the svm cpuid bit. > Doesn't it kill cross-vendor migration? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roedel, Joerg on 5 May 2010 11:20 On Wed, May 05, 2010 at 11:06:59AM -0400, Avi Kivity wrote: > On 05/05/2010 06:04 PM, Joerg Roedel wrote: > > You can roughly check > > for it using the svm cpuid bit. > > Doesn't it kill cross-vendor migration? Enabling Nested SVM kills it anyway, so this is not an issue. AFAIK the feature is not present on Intel CPUs. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 5 May 2010 11:20 On 05/05/2010 06:06 PM, Avi Kivity wrote: > >> You can roughly check >> for it using the svm cpuid bit. > > Doesn't it kill cross-vendor migration? > Oh, the fact that it's in if (nested) protects against that (at least until Intel implements EFER.SVME. So the patch is good. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andre Przywara on 5 May 2010 17:00
Avi Kivity wrote: > On 05/05/2010 05:04 PM, Joerg Roedel wrote: >> This patch enables setting of efer bit 13 which is allowed >> in all SVM capable processors. This is necessary for the >> SLES11 version of Xen 4.0 to boot with nested svm. >> > > Interesting, why does it require it? It does not. Best is you check the patch, which has just been posted yesterday on xen-devel for upstream inclusion: http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00096.html Basically it _tries_ to set the bit via safe_wrmsr() to detect whether its legal (in replacement of the missing CPUID check). Afterwards it resets it. If it available, it allows _guests_ to enable it. AFAIK the only user of this feature is VMware with binary translation running 64bit guests, as they rely on segment limits to protect their hypervisor code from being read from the guest. If I understood this correctly, there is a bug somewhere, maybe even in KVM's nested SVM implementation. Xen is fine with this bit-set provoking a #GP. I haven't had time yet to further investigate this, though. > Obviously it isn't needed since it manages to run on Intel without it. VMware's binary translation relies on VMX for running 64bit guests, on AMD you don't need SVM if you had a K8RevE (dual core 90nm) with this feature. In fact you should not be able to run VMware with 64bit guests inside a KVM guest on an Intel box (without nested VMX, that is). On AMD you can either use nested SVM or this feature. Regards, Andre. > >> /* Intel MSRs. Some also available on other CPUs */ >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> index 74f7b9d..bc087c7 100644 >> --- a/arch/x86/kvm/svm.c >> +++ b/arch/x86/kvm/svm.c >> @@ -610,7 +610,7 @@ static __init int svm_hardware_setup(void) >> >> if (nested) { >> printk(KERN_INFO "kvm: Nested Virtualization enabled\n"); >> - kvm_enable_efer_bits(EFER_SVME); >> + kvm_enable_efer_bits(EFER_SVME | EFER_LMSLE); >> } >> >> for_each_possible_cpu(cpu) { >> > > What if the host doesn't have it? > > Why enable it only for the nested case? It's not svm specific (it's > useful for running non-hvm Xen in non-nested mode). > > Isn't there a cpuid bit for it? If so, it should be exposed to > userspace, and the feature should depend on it. > -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |