From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Subject: Interrupt forwarding Date: Sat, 12 Mar 2005 13:02:37 -0500 Message-ID: <9e473391050312100257800c81@mail.gmail.com> Reply-To: Jon Smirl Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org The subject of interrupt forwarding just came up on lkml. How is this dealt with in Xen? I'm not currently a Xen user so I may be misunderstanding how it works. In Xen I believe you can assign a piece of hardware for exclusive use from a domain. How does this work for shared interrupts, what if the domain receiving the interrupt dies and can't acknowledge it? Here's my comment from lkml.... On Sat, 12 Mar 2005 10:55:21 -0500, Jon Smirl wrote: > I've tried implementing this before (on UML) and could not get around the > interrupt problem. Most interrupts on the x86 architecture are shared. > Disabling the IRQ at the PIC blocks all of the shared IRQs. This works > (hope your userspace handler is last on the shared handler list) until > you have a problem in userspace. > > Once you have a problem in userspace there is no way to acknowledge > the interrupt anymore. I tried to address that by maintaining a timer > and suspending the hardware through the D0 state to reset it. That had > some success. Not acknowledging the interrupt results in an interrupt > loop and reboot. > > The problem can be mitigated by choosing what slot your hardware to > put your hardware in. This can reduce the number of shared interrupts. > If you can get exclusive use of the interrupt this method will work. > > If I were designing a new bus I would make interrupt acknowledge part > of PCI config space in order to allow a single piece of code to > acknowledge them. Since we can't change the bus the only safe way to > do this is to build a hardware specific driver for each device to > acknowledge the interrupt. > > Bottom line is that I could find no reliable solution for handing interrupts. -- Jon Smirl jonsmirl@gmail.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click