kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: Avi Kivity <avi@redhat.com>
Cc: "Roedel, Joerg" <Joerg.Roedel@amd.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/5] KVM: SVM: Allow EFER.LMSLE to be set with nested svm
Date: Wed, 5 May 2010 22:57:00 +0200	[thread overview]
Message-ID: <4BE1DB9C.7000405@amd.com> (raw)
In-Reply-To: <4BE184E3.1010508@redhat.com>

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

  parent reply	other threads:[~2010-05-05 20:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-05 14:04 [PATCH 0/5] Important fixes for KVM-AMD Joerg Roedel
2010-05-05 14:04 ` [PATCH 1/5] KVM: X86: Fix stupid bug in exception reinjection path Joerg Roedel
2010-05-05 14:04 ` [PATCH 2/5] KVM: SVM: Dump vmcb contents on failed vmrun Joerg Roedel
2010-05-05 14:04 ` [PATCH 3/5] KVM: SVM: Fix wrong intercept masks on 32 bit Joerg Roedel
2010-05-05 14:04 ` [PATCH 4/5] KVM: SVM: Allow EFER.LMSLE to be set with nested svm Joerg Roedel
2010-05-05 14:46   ` Avi Kivity
2010-05-05 15:04     ` Joerg Roedel
2010-05-05 15:06       ` Avi Kivity
2010-05-05 15:14         ` Avi Kivity
2010-05-05 15:16         ` Roedel, Joerg
2010-05-05 20:57     ` Andre Przywara [this message]
2010-05-06  9:38       ` Roedel, Joerg
2010-05-06 11:42         ` Avi Kivity
2010-05-05 14:04 ` [PATCH 5/5] KVM: SVM: Don't allow nested guest to VMMCALL into host Joerg Roedel
2010-05-06  8:51 ` [PATCH 0/5] Important fixes for KVM-AMD Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BE1DB9C.7000405@amd.com \
    --to=andre.przywara@amd.com \
    --cc=Joerg.Roedel@amd.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).