From: Paolo Bonzini <[email protected]>
To: Li Kaihang <[email protected]>, [email protected],
Cc: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
Date: 2015-01-19 下午 11:29
Subject: Re: [PATCH 1/1] arch/x86/kvm/vmx.c: Fix external interrupts
inject directly bug with guestos RFLAGS.IF=0
On 15/01/2015 13:36, Li Kaihang wrote:
> This patch fix a external interrupt injecting bug in linux 3.19-rc4.
>
> GuestOS is running and handling some interrupt with RFLAGS.IF = 0 while a
> external interrupt coming,
> then can lead to a vm exit,in this case,we must avoid inject this external
> interrupt or it will generate
> a processor hardware exception causing virtual machine crash.
I do not understand what is happening here.
Between the time the processor starts delivering an external interrupt
to the VM, and the time it decides to do a vm exit because of an
external interrupt in the host, IF becomes 0.
What is the cause of the external interrupt? Why does IF become 0?
> Now, I show more details about this problem:
>
> A general external interrupt processing for a running virtual machine is
> shown in the following:
>
> Step 1:
> a ext intr gen a vm_exit
How did the external interrupt cause the IDT-vectoring information field
to be set? External interrupts for the host are not among the causes
listed in "27.2.3 Information for VM Exits During Event Delivery".
> --> vmx_complete_interrupts --> __vmx_complete_interrupts --> case
> INTR_TYPE_EXT_INR: kvm_queue_interrupt(vcpu, vector, type ==
> INTR_TYPE_SOFT_INTR);
>
> Step 2:
> kvm_x86_ops->handle_external_intr(vcpu);
Why is this relevant? The external interrupt is a vectored event, so it
sets VM-exit interruption information (27.2.2 Information for VM Exits
Due to Vectored Events). It doesn't set the IDT-vectoring information
field.
Li kaihang: I think I make a mistake here that IDT-vectoring information field
is not written by vectored event but is done by Event Delivery.
vm exit during Event Delivery is not triggered by external
interrupt delivery, only vm exit due to vectored event is done so.
Both are completely different, and you are right. I'm very sorry
this patch is wrong.
Paolo
> Step 3:
> get back to vcpu_enter_guest after a while cycle,then run
> inject_pending_event
>
> Step 4:
> if (vcpu->arch.interrupt.pending) {
> kvm_x86_ops->set_irq(vcpu);
> return 0;
> }
>
> Step 5:
> kvm_x86_ops->run(vcpu) --> vm_entry inject vector to guestos IDT
>
> for the above steps, step 4 and 5 will be a processor hardware exception if
> step1 happen while guestos RFLAGS.IF = 0, that is to say, guestos interrupt
> is disabled.
> So we should add a logic to judge in step 1 whether a external interrupt need
> to be pended then inject directly, in the process, we don't need to worry
> about
> this external interrupt lost because the next Step 2 will handle and choose a
> best chance to inject it by virtual interrupt controller.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and
any attachment transmitted herewith) is privileged and confidential and is
intended for the exclusive use of the addressee(s). If you are not an intended
recipient, any disclosure, reproduction, distribution or other dissemination or
use of the information contained is strictly prohibited. If you have received
this mail in error, please delete it and notify us immediately.
