Date: Mon, 22 Nov 2010 09:24:53 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Garrett Cooper <yanegomi@gmail.com>, Andriy Gapon <avg@freebsd.org> Subject: Re: Best way to determine if an IRQ is present Message-ID: <201011220924.53709.jhb@freebsd.org> In-Reply-To: <AANLkTi=%2ByXVrcWDC1QZLA0JWNOQjWG%2Bud_BmwiMXAMXt@mail.gmail.com> References: <AANLkTi=%2ByXVrcWDC1QZLA0JWNOQjWG%2Bud_BmwiMXAMXt@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, November 20, 2010 4:58:02 pm Garrett Cooper wrote: > Trying to do a complete solution for kern/145385, Andriy has > raised concerns about IRQ mapping to CPUs; while I've have put > together more pieces of the puzzle, I'm a bit confused how I determine > whether or not an IRQ is available for use. > Sure, I could linear probe a series of IRQs, but that would > probably be expensive, and different architectures treat IRQs > differently, so building assumptions based on the fact that IRQ > hierarchy is done in a particular order is probably not the best thing > to do. > I've poked around kern/kern_cpuset.c and kern/kern_intr.c a bit > but I may have missed something important... Well, the real solution is actually larger than described in the PR. What you really want to do is take the logical CPUs offline when they are "halted". Taking a CPU offline should trigger an EVENTHANDLER that various bits of code could invoke. In the case of platforms that support binding interrupts to CPUs (x86 and sparc64 at least), they would install an event handler that searches the MD interrupt tables (e.g. the interrupt_sources[] array on x86) and move bound interrupts to other CPUs. However, I think all the interrupt bits will be MD, not MI. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011220924.53709.jhb>