08af757235
25927-x86-domctl-ioport-mapping-range.patch 25929-tmem-restore-pool-version.patch 25931-x86-domctl-iomem-mapping-checks.patch 25940-x86-S3-flush-cache.patch 25952-x86-MMIO-remap-permissions.patch 25961-x86-HPET-interrupts.patch 25962-x86-assign-irq-vector-old.patch 25965-x86-ucode-Intel-resume.patch OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=205
36 lines
1.4 KiB
Diff
36 lines
1.4 KiB
Diff
# HG changeset patch
|
|
# User Jan Beulich <jbeulich@suse.com>
|
|
# Date 1348817014 -7200
|
|
# Node ID 41f523f1b5e5af9cf8e85160f2412456da83050f
|
|
# Parent 6a581212909478bba0c7b4dfc6c370270dee825c
|
|
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>
|
|
|
|
--- 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;
|
|
|