lkml.org 
[lkml]   [2014]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/4] KVM: ioapic: clear IRR for edge-triggered interrupts at delivery
Il 21/03/2014 19:34, Eduardo Habkost ha scritto:
>> > + if (irqe.trig_mode == IOAPIC_EDGE_TRIG)
>> > + ioapic->irr &= ~(1 << irq);
>> > +
> Now, every call to ioapic_service() for an edge interrupt clears the IRR
> bit immediately (assuming the mask is unset).
>
> If the IRR bit is immediately zero on delivery, why won't this break the
> edge detection logic on kvm_ioapic_set_irq()? Am I missing some
> additional detail?

That logic will still trigger if the interrupt is masked in the IOAPIC's
ioredirtbl.

> In other words, won't this cause spurious interrupts if
> kvm_ioapic_set_irq(..., true) is called twice?

Yes, and this is why I don't like this patch very much. Basically it
leaves it up to userspace to only send edge-triggered interrupts on an
actual rising edge and never do two consecutive kvm_ioapic_set_irq(...,
true) ioctls.

On the other hand, treating IRR this way is how QEMU's userspace IOAPIC
works already, so the chance of bugs is smaller than any alternative;
and the alternatives aren't that good either. For example, I had
thought about using the remote_irr bit to store the status. In order to
keep the old behavior where remote_irr is zero for edge-triggered
interrupts, the bit can be masked out when reading the ioredirtbl.

KVM_SET_IRQCHIP then could look at irr & ~remote_irr to find interrupts
that have to be delivered. However, I was afraid that this would cause
problems on migration from new to old kernels, which would let userspace
see remote_irr=1 for edge-triggered interrupts.

Paolo


\
 
 \ /
  Last update: 2014-03-22 09:21    [W:0.186 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site