Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.09.12 at 17:33, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 27/09/12 16:04, Jan Beulich wrote:
>>>>> On 27.09.12 at 16:57, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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 <jbeulich@xxxxxxxx>
>>>> ---
>>>> 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.

With irq_vector[] not even in existence anymore, I wonder
whether we shouldn't go back to zero.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel