From: Paolo Bonzini <pbonzini@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
gleb@kernel.org, mtosatti@redhat.com, alex.williamson@redhat.com,
jan.kiszka@siemens.com
Subject: Re: [PATCH v2 2/4] KVM: ioapic: clear IRR for edge-triggered interrupts at delivery
Date: Sat, 22 Mar 2014 08:48:22 +0100 [thread overview]
Message-ID: <532D4046.9030302@redhat.com> (raw)
In-Reply-To: <20140321183426.GD10819@otherpad.lan.raisama.net>
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
next prev parent reply other threads:[~2014-03-22 7:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 9:27 [PATCH v2 0/4] KVM: cleanup ioapic and fix KVM_SET_IRQCHIP with irr != 0 Paolo Bonzini
2014-03-21 9:27 ` [PATCH v2 1/4] KVM: ioapic: merge ioapic_deliver into ioapic_service Paolo Bonzini
2014-03-21 17:39 ` Eduardo Habkost
2014-03-21 9:27 ` [PATCH v2 2/4] KVM: ioapic: clear IRR for edge-triggered interrupts at delivery Paolo Bonzini
2014-03-21 18:34 ` Eduardo Habkost
2014-03-22 7:48 ` Paolo Bonzini [this message]
2014-03-21 9:28 ` [PATCH v2 3/4] KVM: ioapic: extract body of kvm_ioapic_set_irq Paolo Bonzini
2014-03-21 18:58 ` Radim Krčmář
2014-03-23 8:44 ` Paolo Bonzini
2014-03-24 17:55 ` Radim Krčmář
2014-03-21 9:28 ` [PATCH v2 4/4] KVM: ioapic: reinject pending interrupts on KVM_SET_IRQCHIP Paolo Bonzini
2014-03-21 14:00 ` Alex Williamson
2014-03-24 17:58 ` Radim Krčmář
2014-03-24 18:14 ` Paolo Bonzini
2014-03-24 19:28 ` Radim Krčmář
2014-03-24 17:59 ` [PATCH v2 0/4] KVM: cleanup ioapic and fix KVM_SET_IRQCHIP with irr != 0 Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=532D4046.9030302@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=ehabkost@redhat.com \
--cc=gleb@kernel.org \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.