On Fri, May 07, 2021 at 05:22:07PM +0000, Sean Christopherson wrote:
> On Fri, May 07, 2021, Marcelo Tosatti wrote:
> > Index: kvm/arch/x86/kvm/vmx/posted_intr.c
> > ===================================================================
> > --- kvm.orig/arch/x86/kvm/vmx/posted_intr.c
> > +++ kvm/arch/x86/kvm/vmx/posted_intr.c
> > @@ -203,6 +203,25 @@ void pi_post_block(struct kvm_vcpu *vcpu
> > local_irq_enable();
> > }
> >
> > +int vmx_vcpu_check_block(struct kvm_vcpu *vcpu)
> > +{
> > + struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > +
> > + if (!irq_remapping_cap(IRQ_POSTING_CAP))
> > + return 0;
> > +
> > + if (!kvm_vcpu_apicv_active(vcpu))
> > + return 0;
> > +
> > + if (!kvm_arch_has_assigned_device(vcpu->kvm))
> > + return 0;
> > +
> > + if (pi_desc->nv == POSTED_INTR_WAKEUP_VECTOR)
> > + return 0;
> > +
> > + return 1;
>
> IIUC, the logic is to bail out of the block loop if the VM has an assigned
> device, but the blocking vCPU didn't reconfigure the PI.NV to the wakeup vector,
> i.e. the assigned device came along after the initial check in vcpu_block().
> That makes sense, but you can add a comment somewhere in/above this function?
Wondering whether we should add a pi_test_on() check in kvm_vcpu_has_events()
somehow, so that even without customized ->vcpu_check_block we should be able
to break the block loop (as kvm_arch_vcpu_runnable will return true properly)?
--
Peter Xu
