DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0E1BD64D28
Subject: Re: [PATCH] KVM: nVMX: Fix exception injection
To: Wanpeng Li <kernellwp@gmail.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org
Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>
References: <1496460115-12654-1-git-send-email-wanpeng.li@hotmail.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <2ba5e53d-14f4-14a1-0084-a8b521a3ec3e@redhat.com>
Date: Mon, 5 Jun 2017 14:07:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <1496460115-12654-1-git-send-email-wanpeng.li@hotmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2086
Lines: 49


On 03/06/2017 05:21, Wanpeng Li wrote:
> Commit 0b6ac343fc (KVM: nVMX: Correct handling of exception injection) mentioned 
> that "KVM wants to inject page-faults which it got to the guest. This function 
> assumes it is called with the exit reason in vmcs02 being a #PF exception". 
> Commit e011c663 (KVM: nVMX: Check all exceptions for intercept during delivery to 
> L2) allows to check all exceptions for intercept during delivery to L2. However, 
> there is no guarantee the exit reason is exception currently, when there is an 
> external interrupt occurred on host, maybe a time interrupt for host which should 
> not be injected to guest, and somewhere queues an exception, then the function 
> nested_vmx_check_exception() will be called and the vmexit emulation codes will 
> try to emulate the "Acknowledge interrupt on exit" behavior, the warning is 
> triggered.
> 
> This patch fixes it by confirming to inject exception to the guest when the exit 
> reason in vmcs02 is exception. 

I am confused.  On one hand, the comment originally "this is the only
case in which KVM injects a #PF when L2 is running", but I'm not sure
it's true.  For example, KVM could emulate a movs while running L2.  If
the source is MMIO and the destination is a missing page, the original
failure could be an EPT misconfig, but the access to the destination
would cause a #PF in the guest (could be a nice testcase for
kvm-unit-tests, BTW :)).

On the other hand, why would you reuse to_vmx(vcpu)->exit_reason in
nested_vmx_check_exception?  Would the following fix the bug:

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9b4b5d6dcd34..ca5d2b93385c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2425,7 +2425,7 @@ static int nested_vmx_check_exception(struct
kvm_vcpu *vcpu, unsigned nr)
 	if (!(vmcs12->exception_bitmap & (1u << nr)))
 		return 0;

-	nested_vmx_vmexit(vcpu, to_vmx(vcpu)->exit_reason,
+	nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
 			  vmcs_read32(VM_EXIT_INTR_INFO),
 			  vmcs_readl(EXIT_QUALIFICATION));
 	return 1;

?

Thanks,

Paolo