From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752042AbXBCKXk (ORCPT ); Sat, 3 Feb 2007 05:23:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751947AbXBCKXk (ORCPT ); Sat, 3 Feb 2007 05:23:40 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:46746 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751873AbXBCKXj (ORCPT ); Sat, 3 Feb 2007 05:23:39 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Andi Kleen Cc: Andrew Morton , linux-kernel@vger.kernel.org, "Lu, Yinghai" , "Luigi Genoni" , Ingo Molnar , Natalie Protasevich Subject: Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration. References: <200701221116.13154.luigi.genoni@pirelli.com> <200702031101.22313.ak@suse.de> Date: Sat, 03 Feb 2007 03:22:33 -0700 In-Reply-To: <200702031101.22313.ak@suse.de> (Andi Kleen's message of "Sat, 3 Feb 2007 11:01:22 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andi Kleen writes: >> Once the migration operation is complete we know we will receive >> no more interrupts on this vector so the irq pending state for >> this irq will no longer be updated. If the irq is not pending and >> we are in the intermediate state we immediately free the vector, >> otherwise in we free the vector in do_IRQ when the pending irq >> arrives. > > Ok for me, although the magic numbers are a little nasty. You must be talking about (vector/32) *0x10. The 32 is the number of bits and 0x10 the gap between apic registers. I couldn't think of a better form. If someone can think of a better way it probably warrants a cleanup patch at some point. > What about i386? i386 does not handle this case but since it is still globally allocating all of it's vectors and never changes it's vectors during migration it is totally harmless when an irq comes in on a cpu other than the one we are expecting it on. Eric