Hi Jim, 2017-07-19 2:47 GMT+08:00 Jim Mattson <jmattson@xxxxxxxxxx>: > Why do we expect the VM_EXIT_INTR_INFO and EXIT_QUALIFICATION fields > of the VMCS to have the correct values for the injected exception? Good point, I think we should synthesize VM_EXIT_INTR_INFO and EXIT_QUALIFICATION manually, I will post a patch for it. Btw, how about setting EXIT_QULIFICATION to vcpu->arch.cr2 for the page fault exception and 0 for other exceptions? Regards, Wanpeng Li > > On Mon, Jun 5, 2017 at 5:19 AM, Wanpeng Li <kernellwp@xxxxxxxxx> wrote: >> 2017-06-05 20:07 GMT+08:00 Paolo Bonzini <pbonzini@xxxxxxxxxx>: >>> >>> >>> 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; >>> >> >> You are right. >> >> Regards, >> Wanpeng Li
