From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 22 14:53:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85066106567A; Mon, 22 Nov 2010 14:53:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 567B18FC0C; Mon, 22 Nov 2010 14:53:36 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0BD1846B03; Mon, 22 Nov 2010 09:53:36 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2C3CF8A027; Mon, 22 Nov 2010 09:53:35 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 22 Nov 2010 09:24:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011220924.53709.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 22 Nov 2010 09:53:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Garrett Cooper , Andriy Gapon Subject: Re: Best way to determine if an IRQ is present X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 14:53:36 -0000 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