x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()

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@suse.com>
Acked-by: Keir Fraser <keir@xen.org>

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index db345914c0d6d89f0499f00434f6d6bb51d8e9a4..ced46a6dc3b6ac84539ccb9b9a55d7777bf3f4fd 100644 (file)
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -430,8 +430,7 @@ static int __assign_irq_vector(
      * 0x80, because int 0x80 is hm, kind of importantish. ;)
      */
     static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
-    unsigned int old_vector;
-    int cpu, err;
+    int cpu, err, old_vector;
     cpumask_t tmp_mask;
     vmask_t *irq_used_vectors = NULL;