Re: [PATCH 5/5] KVM: arm/arm64: kvm_arch_vcpu_runnable: don't miss injected irqs

Christoffer Dall
2017-10-18T14:13:49Z

On Wed, Oct 18, 2017 at 3:55 PM, Andrew Jones <drjones@redhat.com> wrote:
> On Wed, Oct 18, 2017 at 03:18:43PM +0200, Christoffer Dall wrote:
>> On Wed, Oct 18, 2017 at 02:13:05PM +0200, Andrew Jones wrote:
>> > On Sat, Oct 14, 2017 at 09:13:35PM +0200, Christoffer Dall wrote:
>> > > On Fri, Sep 29, 2017 at 01:30:41PM +0200, Andrew Jones wrote:
>> > > > When the vPMU is in use if a VCPU's perf event overflow handler
>> > > > were to fire after the VCPU started waiting, then the wake up
>> > > > done by the kvm_vcpu_kick() call in the handler would do nothing,
>> > > > as no "pmu overflow" state is checked in kvm_arch_vcpu_runnable().
>> > > > Fix this by checking the IRQ_PENDING VCPU request in runnable().
>> > > > Checking the request also sufficiently covers all the cases that
>> > > > kvm_vgic_vcpu_pending_irq() cover, so we can just replace that.
>> > > >
>> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
>> > > > ---
>> > > > virt/kvm/arm/arm.c | 2 +-
>> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> > > > index 5bc9b0d2fd0f..725527f491e4 100644
>> > > > --- a/virt/kvm/arm/arm.c
>> > > > +++ b/virt/kvm/arm/arm.c
>> > > > @@ -423,7 +423,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>> > > > return !vcpu_should_sleep(vcpu) &&
>> > > > (vcpu->arch.mp_state != KVM_MP_STATE_HALTED ||
>> > > > (!!vcpu->arch.irq_lines ||
>> > > > - kvm_vgic_vcpu_pending_irq(vcpu)));
>> > > > + kvm_test_request(KVM_REQ_IRQ_PENDING, vcpu)));
>> > >
>> > > So what if a VCPU blocks, a device raises an IRQ, the VCPU loops around,
>> > > clears the KVM_REQ_IRQ_PENDING flag, enters the VM again, which does
>> > > another WFI (for fun), and you end up here again with a pending IRQ but
>> > > no KVM_REQ_IRQ_PENDING flag anymore. Doesn't this end up incorrectly
>> > > stalling the VCPU?
>> >
>> > Hmm, I see what you mean. I'm sorry I missed that.
>> >
>> > >
>> > > I don't think that a transient flag will work for a persistent binary
>> > > state here.
>> >
>> > I think we can fix it by adding
>> >
>> > if (kvm_vgic_vcpu_pending_irq(vcpu))
>> > kvm_make_request(KVM_REQ_IRQ_PENDING, vcpu);
>> >
>> > to kvm_vgic_sync_hwstate(), if the additional overhead would be
>> > acceptable. Otherwise we need to find some other way to ensure
>> > vPMU irqs unblock the VCPU.
>> >
>>
>> I think you just need to check
>> kvm_vgic_vcpu_pending_irq() ||
>> kvm_test_request(KVM_REQ_IRQ_PENDING, vcpu)
>>
>> Wouldn't that fix it?
>
> It would. I was just hoping to eliminate the lock-taking
> kvm_vgic_vcpu_pending_irq() call from kvm_arch_vcpu_runnable()
> though, as kvm_arch_vcpu_runnable() may be called repeatedly
> during halt polling.
>

Could we make it so that the KVM_REQ_IRQ_PENDING request only gets
cleared when there are really no more pending IRQs for the VCPU then?

Getting rid of the lock would be potentially good from a latency point
of view, but then again, it's slow to wake up from WFI, and the lock
is per-VCPU so not likely to be contended is it?

Thanks,
-Christoffer