linux-kernel - Re: [PATCH v2 2/4] KVM: ioapic: clear IRR for edge-triggered interrupts at delivery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <532D4046.9030302@redhat.com>
Date:	Sat, 22 Mar 2014 08:48:22 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Eduardo Habkost <ehabkost@...hat.com>
CC:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org, gleb@...nel.org,
	mtosatti@...hat.com, alex.williamson@...hat.com,
	jan.kiszka@...mens.com
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/