On Tue, Nov 24, 2020 at 3:09 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > 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. This logic only applies to when the IPI is *sent*. AFAIK, there is no bound on the amount of time that can elapse before the IPI is *received*. (In fact, virtualization depends on this.)
