Message ID | 20210215094506.1196119-1-groug@kaod.org (mailing list archive) |
---|---|
State | Accepted |
Headers | show |
Series | [v2] powerpc/pseries: Don't enforce MSI affinity with kdump | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (626a6c3d2e20da80aaa710104f34ea6037b28b33) |
snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 37 lines checked |
snowpatch_ozlabs/needsstable | success | Patch is tagged for stable |
On Mon, 15 Feb 2021 10:45:06 +0100, Greg Kurz wrote: > Depending on the number of online CPUs in the original kernel, it is > likely for CPU #0 to be offline in a kdump kernel. The associated IRQs > in the affinity mappings provided by irq_create_affinity_masks() are > thus not started by irq_startup(), as per-design with managed IRQs. > > This can be a problem with multi-queue block devices driven by blk-mq : > such a non-started IRQ is very likely paired with the single queue > enforced by blk-mq during kdump (see blk_mq_alloc_tag_set()). This > causes the device to remain silent and likely hangs the guest at > some point. > > [...] Applied to powerpc/fixes. [1/1] powerpc/pseries: Don't enforce MSI affinity with kdump https://git.kernel.org/powerpc/c/f9619d5e5174867536b7e558683bc4408eab833f cheers
diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c index b3ac2455faad..637300330507 100644 --- a/arch/powerpc/platforms/pseries/msi.c +++ b/arch/powerpc/platforms/pseries/msi.c @@ -4,6 +4,7 @@ * Copyright 2006-2007 Michael Ellerman, IBM Corp. */ +#include <linux/crash_dump.h> #include <linux/device.h> #include <linux/irq.h> #include <linux/msi.h> @@ -458,8 +459,28 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type) return hwirq; } - virq = irq_create_mapping_affinity(NULL, hwirq, - entry->affinity); + /* + * Depending on the number of online CPUs in the original + * kernel, it is likely for CPU #0 to be offline in a kdump + * kernel. The associated IRQs in the affinity mappings + * provided by irq_create_affinity_masks() are thus not + * started by irq_startup(), as per-design for managed IRQs. + * This can be a problem with multi-queue block devices driven + * by blk-mq : such a non-started IRQ is very likely paired + * with the single queue enforced by blk-mq during kdump (see + * blk_mq_alloc_tag_set()). This causes the device to remain + * silent and likely hangs the guest at some point. + * + * We don't really care for fine-grained affinity when doing + * kdump actually : simply ignore the pre-computed affinity + * masks in this case and let the default mask with all CPUs + * be used when creating the IRQ mappings. + */ + if (is_kdump_kernel()) + virq = irq_create_mapping(NULL, hwirq); + else + virq = irq_create_mapping_affinity(NULL, hwirq, + entry->affinity); if (!virq) { pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);