public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Liran Alon <LIRAN.ALON@ORACLE.COM>
To: Paolo Bonzini <pbonzini@redhat.com>,
	rkrcmar@redhat.com, kvm@vger.kernel.org
Cc: jmattson@google.com, idan.brown@ORACLE.COM,
	Konrad Rzeszutek Wilk <konrad.wilk@ORACLE.COM>
Subject: Re: [PATCH] KVM: nVMX/nSVM: Don't intercept #UD when running L2
Date: Mon, 06 Nov 2017 13:02:05 +0200	[thread overview]
Message-ID: <5A00412D.60604@ORACLE.COM> (raw)
In-Reply-To: <e52da821-9842-cfa2-bf59-6f1aa6a67692@redhat.com>



On 06/11/17 11:27, Paolo Bonzini wrote:
> On 05/11/2017 17:15, Liran Alon wrote:
>> When running L2, #UD should be intercepted by L1 or just forwarded
>> directly to L2. It should not reach L0 x86 emulator.
>> Therefore, set intercept for #UD only based on L1 exception-bitmap.
>>
>> Also add BUG_ON() on L0 #UD intercept handlers to make sure it is never
>> reached while running L2.
>>
>> This improves commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD while
>> in guest mode") by removing an unnecessary exit from L2 to L0 on #UD
>> when L1 doesn't intercept it.
>>
>> In addition, SVM L0 #UD intercept handler doesn't handle correctly the
>> case it is raised from L2. In this case, it should forward the #UD to
>> guest instead of x86 emulator. As done in VMX #UD intercept handler.
>> This commit fixes this issue as-well.
>>
>> Signed-off-by: Liran Alon <liran.alon@oracle.com>
>> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>   arch/x86/kvm/svm.c | 4 +++-
>>   arch/x86/kvm/vmx.c | 9 ++++-----
>>   2 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index 0e68f0b3cbf7..1c7f76a417e7 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -1221,7 +1221,8 @@ static void init_vmcb(struct vcpu_svm *svm)
>>   	set_dr_intercepts(svm);
>>
>>   	set_exception_intercept(svm, PF_VECTOR);
>> -	set_exception_intercept(svm, UD_VECTOR);
>> +	if (!is_guest_mode(&svm->vcpu))
>> +		set_exception_intercept(svm, UD_VECTOR);
>>   	set_exception_intercept(svm, MC_VECTOR);
>>   	set_exception_intercept(svm, AC_VECTOR);
>>   	set_exception_intercept(svm, DB_VECTOR);
>
> This is not called on every vmexit.  The right place to touch is
> recalc_intercepts.  Then on vmexit it will be automatically restored
> when nested_svm_vmexit calls copy_vmcb_control_area.
Agreed. My bad. Will fix in v2 of this commit.
>
>> @@ -2188,6 +2189,7 @@ static int ud_interception(struct vcpu_svm *svm)
>>   {
>>   	int er;
>>
>> +	BUG_ON(is_guest_mode(&svm->vcpu));
>>   	er = emulate_instruction(&svm->vcpu, EMULTYPE_TRAP_UD);
>>   	if (er != EMULATE_DONE)
>>   		kvm_queue_exception(&svm->vcpu, UD_VECTOR);
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 95a01609d7ee..5e2c47dd0c83 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -1878,7 +1878,7 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
>>   {
>>   	u32 eb;
>>
>> -	eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
>> +	eb = (1u << PF_VECTOR) | (1u << MC_VECTOR) |
>>   	     (1u << DB_VECTOR) | (1u << AC_VECTOR);
>>   	if ((vcpu->guest_debug &
>>   	     (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
>> @@ -1896,6 +1896,8 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
>>   	 */
>>   	if (is_guest_mode(vcpu))
>>   		eb |= get_vmcs12(vcpu)->exception_bitmap;
>> +	else
>> +		eb |= 1u << UD_VECTOR;
>
> It's a nit, but since you have to send a v2, I'd prefer to keep
> UD_VECTOR above and clear it here.
I think your suggestion could be problematic.
In case (to_vmx(vcpu)->rmode.vm86_active == true) then we would like to 
intercept all exceptions and therefore not clear UD_VECTOR.
This is why I preferred this approach.
>
> Thanks,
>
> Paolo
>
>>   	vmcs_write32(EXCEPTION_BITMAP, eb);
>>   }
>> @@ -5881,10 +5883,7 @@ static int handle_exception(struct kvm_vcpu *vcpu)
>>   		return 1;  /* already handled by vmx_vcpu_run() */
>>
>>   	if (is_invalid_opcode(intr_info)) {
>> -		if (is_guest_mode(vcpu)) {
>> -			kvm_queue_exception(vcpu, UD_VECTOR);
>> -			return 1;
>> -		}
>> +		BUG_ON(is_guest_mode(vcpu));
>>   		er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD);
>>   		if (er != EMULATE_DONE)
>>   			kvm_queue_exception(vcpu, UD_VECTOR);
>>
>

  reply	other threads:[~2017-11-06 11:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-05 16:15 [PATCH] KVM: nVMX/nSVM: Don't intercept #UD when running L2 Liran Alon
2017-11-06  9:27 ` Paolo Bonzini
2017-11-06 11:02   ` Liran Alon [this message]
2017-11-06 11:24     ` Paolo Bonzini
2017-11-06 12:36 ` Paolo Bonzini

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=5A00412D.60604@ORACLE.COM \
    --to=liran.alon@oracle.com \
    --cc=idan.brown@ORACLE.COM \
    --cc=jmattson@google.com \
    --cc=konrad.wilk@ORACLE.COM \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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