On 27/12/17 12:06, Paolo Bonzini wrote:
On 24/12/2017 17:12, Liran Alon wrote:
+ kvm_before_handle_host_interrupts(vcpu);
local_irq_enable();
+ kvm_after_handle_host_interrupts(vcpu);
preempt_enable();
This should be around the call to kvm_x86_ops->handle_external_intr, not
here.
Also, perhaps you could: 1) do the kvm_before_handle_* unconditionally
before the point where NMIs would be injected; 2) remove the
kvm_after_handle_* from vmx_complete_atomic_exit and svm_vcpu_run; 3)
only do kvm_after_handle_* after kvm_x86_ops->handle_external_intr, not
before it.
Paolo
The intention of this change was that later commit can handle the case
where nested posted-interrupts processing is triggered by self-IPI but
the CPU has immediately exited guest after resume because of another
external interrupt (different than POSTED_INTR_NESTED_VECTOR).
In this case, the POSTED_INTR_NESTED_VECTOR interrupt will be triggered
on host after vcpu_enter_guest() calls local_irq_enable(). And our
handler should re-set vmx->nested.pi_pending to true so that on next
vmentry, vmx_complete_nested_posted_interrupt() will re-trigger a self-IPI.
Therefore it is not sufficient to put calls to
kvm_{before,after}_handle_host_interrupts around call to
kvm_x86_ops->handle_external_intr().
But you are correct that it makes sense to also put these calls around
that call-site as-well.
So as I see it, we have 2 alternatives here:
1. Just add calls around kvm_x86_ops->handle_external_intr().
2. Go with your suggestion but with a more intuitive approach:
Change only vcpu_enter_guest() such that:
a. Will call kvm_before_handle_host_interrupts() after setting
vcpu->mode = IN_GUEST_MODE.
b. Will call kvm_after_handle_host_interrupts() after calls to
local_irq_enable() (One in case there is a pending KVM requst and one
after guest was run and we exited guest normally).
What do you think?
Regards,
-Liran
