On 24/11/20 01:10, Oliver Upton wrote:
but you also have to do the same*in the PINV handler*
sysvec_kvm_posted_intr_nested_ipi too, to handle the case where the
L2->L0 vmexit races against sending the IPI.
Indeed, there is a race but are we assured that the target vCPU thread
is scheduled on the target CPU when that IPI arrives?
This would only happen if the source vCPU saw vcpu->mode ==
IN_GUEST_MODE for the target vCPU. Thus there are three cases:
1) the vCPU is in non-root mode. This is easy. :)
2) the vCPU hasn't entered the VM yet. Then posted interrupt IPIs are
delayed after guest entry and ensured to result in virtual interrupt
delivery, just like case 1.
3) the vCPU has left the VM but it hasn't reached
vcpu->mode = OUTSIDE_GUEST_MODE;
smp_wmb();
yet. Then the interrupt will be right after that moment, at.
kvm_before_interrupt(vcpu);
local_irq_enable();
++vcpu->stat.exits;
local_irq_disable();
kvm_after_interrupt(vcpu);
Anything else will cause kvm_vcpu_trigger_posted_interrupt(vcpu, true)
to return false instead of sending an IPI.
Paolo
