Re: [PATCH] KVM: nVMX: Fix exception injection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux