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@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.

--- 2012-09-21.orig/xen/arch/x86/irq.c	2012-09-19 08:48:33.000000000 +0200
+++ 2012-09-21/xen/arch/x86/irq.c	2012-09-27 13:33:45.000000000 +0200
@@ -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;