All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.