From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: UIO interrupts being lost Date: Fri, 25 Jun 2010 13:32:40 +0300 Message-ID: <20100625103240.GB16321@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Cam Macdonell , kvm@vger.kernel.org, qemu-devel@nongnu.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46023 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754865Ab0FYKhi (ORCPT ); Fri, 25 Jun 2010 06:37:38 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 24, 2010 at 05:43:15PM -0600, Cam Macdonell wrote: > Hi Michael, > > I'm trying to write a uio driver for my shared memory device for KVM > and I'm running into a situation where several interrupts in quick > succession are not all triggering the callback function in my kernel > UIO driver, say 2 out of 5. My driver does not set the Interrupt > Disable bit and if it helps, I'm using MSI-X interrupts. Even without > the interrupt disable bit set, is there still a window where > successive interrupts can be lost if they arrive too quickly? > > Thanks, > Cam Yes, I think so: if an interrupt is delivered when ISR is running, it gets queued, but a second one gets lost. A queueing mechanism is necessary to avoid losing information, e.g. virtio implements exactly that. Why don't you reuse virtio for signalling? If I understand what Anthony said correctly, he objected to the specific implementation, not to the idea of reusing virtio spec and code. -- MST