On Fri, May 07, 2021 at 03:29:05PM -0400, Peter Xu wrote:
> 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)?
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
{
int ret = -EINTR;
int idx = srcu_read_lock(&vcpu->kvm->srcu);
if (kvm_arch_vcpu_runnable(vcpu)) {
kvm_make_request(KVM_REQ_UNHALT, vcpu); <---
goto out;
}
Don't want to unhalt the vcpu.
