On Tue, Mar 19, 2013 at 12:42:01PM +0000, Zhang, Yang Z wrote:
> >>>> local_irq_disable();
> >>>> + kvm_x86_ops->posted_intr_clear_on(vcpu);
> >>>> +
> >>> Why is this separate from pir_to_irr syncing?
> >> This is the result of discussion with Marcelo. It is more reasonable to
> >> put it here to avoid unnecessary posted interrupt between:
> >>
> >> vcpu->mode = IN_GUEST_MODE;
> >>
> >> <--interrupt may arrived here and this is unnecessary.
> >>
> >> local_irq_disable();
> >>
> >
> > But this still can happen as far as I see:
> >
> > vcpu0 vcpu1:
> > pi_test_and_set_pir() kvm_make_request(KVM_REQ_EVENT)
> > if (KVM_REQ_EVENT)
> > sync_pir_to_irr()
> > vcpu->mode =
> > IN_GUEST_MODE;
> > if (vcpu->mode == IN_GUEST_MODE)
> > if (!pi_test_and_set_on())
> > apic->send_IPI_mask()
> > --> IPI arrives here
> > local_irq_disable();
> > posted_intr_clear_on()
> Current solution is trying to block other Posted Interrupt from other VCPUs
> at same time. It only mitigates it but cannot solve it. The case you
> mentioned still exists but it should be rare.
>
I am not sure I follow. What scenario exactly are you talking about. I
looked over past discussion about it and saw that Marcelo gives an
example how IPI can be lost, but I think that's because we set "on" bit
after KVM_REQ_EVENT:
cpu0 cpu1 vcpu0
test_and_set_bit(PIR-A)
set KVM_REQ_EVENT
process REQ_EVENT
PIR-A->IRR
vcpu->mode=IN_GUEST
if (vcpu0->guest_mode)
if (!t_a_s_bit(PIR notif))
send IPI
linux_pir_handler
t_a_s_b(PIR-B)=1
no PIR IPI sent
But what if on delivery we do:
pi_test_and_set_pir()
r = pi_test_and_set_on()
kvm_make_request(KVM_REQ_EVENT)
if (!r)
send_IPI_mask()
else
kvm_vcpu_kick()
And on vcpu entry we do:
if (kvm_check_request(KVM_REQ_EVENT)
if (test_and_clear_bit(on))
kvm_apic_update_irr()
What are the downsides? Can we lost interrupts this way?
> > May be move vcpu->mode = IN_GUEST_MODE after local_irq_disable()?
> Yes, this will solve it. But I am not sure whether it will introduce any
> regressions. Is there any check relies on this sequence?
>
Do not think so.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
