From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/IRQ: fix valid-old-vector checks in __assign_irq_vector() Date: Thu, 27 Sep 2012 16:33:50 +0100 Message-ID: <506471DE.4090708@citrix.com> References: <506483CC020000780009E42C@nat28.tlf.novell.com> <5064695B.1010805@citrix.com> <50648725020000780009E462@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50648725020000780009E462@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 27/09/12 16:04, Jan Beulich wrote: >>>> On 27.09.12 at 16:57, Andrew Cooper wrote: >> On 27/09/12 15:50, Jan Beulich wrote: >>> There are two greater-than-zero checks for the old vector retrieved, >>> which don't work when a negative value got stashed into the respective >>> arch_irq_desc field. The effect of this was that for interrupts that >>> are intended to get their affinity adjusted the first time before the >>> first interrupt occurs, the affinity change would fail, because the >>> original vector assignment would have caused the move_in_progress flag >>> to get set (which causes subsequent re-assignments to fail until it >>> gets cleared, which only happens from the ->ack() actor, i.e. when an >>> interrupt actually occurred). >>> >>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by >>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1). >>> >>> Signed-off-by: Jan Beulich >>> --- >>> I have to admit that I don't understand why the value got changed in >>> the first place: 0 is as invalid a value as -1 for a vector to be used >>> for delivering hardware interrupts. >> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html >> >> It was a suggestion for consistency with using -1 elsewhere in the irq >> code to mean unassigned. > Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED, > but not to make that resolve to -1. My claim is that this manifest > constant could easily resolve to zero instead. > > Jan Ah - it was in the following email. "Yes - I missed that. However, IRQ_VECTOR_UNASSIGNED should be -1 instead of 0, as the first 32 entries of irq_vector have 0 entries which are not unassigned." Which was my justification of using -1 as opposed to 0. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com