On 09/17/2012 02:28 PM, Li, Jiongxi wrote:
>> > +++ b/arch/x86/kvm/lapic.c
>> > @@ -499,8 +499,13 @@ static int __apic_accept_irq(struct kvm_lapic *apic,
>> int delivery_mode,
>> > if (trig_mode) {
>> > apic_debug("level trig mode for vector %d", vector);
>> > apic_set_vector(vector, apic->regs + APIC_TMR);
>> > - } else
>> > + if (kvm_apic_vid_enabled(vcpu))
>> > + kvm_x86_ops->set_eoi_exitmap(vcpu, vector, 1);
>> > + } else {
>> > apic_clear_vector(vector, apic->regs + APIC_TMR);
>> > + if (kvm_apic_vid_enabled(vcpu))
>> > + kvm_x86_ops->set_eoi_exitmap(vcpu, vector, 0);
>> > + }
>>
>> This is way too late. The flow should come from the IOAPIC and PIC, when
>> setting up an irq, to the local APIC.
>>
> I just wonder why you think it is too late to do that. Out of the reason
> that If post interrupt is enabled, here won't be called?
That was not the reason, but it is true as well. With posted interrupts
this path is bypassed completely.
> Or because we
> can't set eoi bitmap for PIT here just according to TMR and needs to set
> it in a place where can recognize the PIT vector?
Yes. When we register an irq ack notifier we know the gsi and therefore
the vector, and can update the eoi exit bitmap accordingly. This works
with posted interrupts as well. Note we have to rebuild the table when
the ioapic redirection bitmap is updated (or the PIC irq base, or ELCR
change, etc.)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
