From: Avi Kivity on
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
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
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
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
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/