From: Greg Kroah-Hartman Date: Sat, 23 Jul 2022 15:15:14 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.10.133~44 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2b71f8ec01ed3e87bcfc0d64a926351aebd36ef0;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: pci-hv-fix-hv_arch_irq_unmask-for-multi-msi.patch pci-hv-fix-interrupt-mapping-for-multi-msi.patch pci-hv-fix-multi-msi-to-allow-more-than-one-msi-vector.patch pci-hv-reuse-existing-irte-allocation-in-compose_msi_msg.patch --- diff --git a/queue-5.10/pci-hv-fix-hv_arch_irq_unmask-for-multi-msi.patch b/queue-5.10/pci-hv-fix-hv_arch_irq_unmask-for-multi-msi.patch new file mode 100644 index 00000000000..e3cda13b76d --- /dev/null +++ b/queue-5.10/pci-hv-fix-hv_arch_irq_unmask-for-multi-msi.patch @@ -0,0 +1,96 @@ +From foo@baz Sat Jul 23 05:13:20 PM CEST 2022 +From: Carl Vanderlip +Date: Fri, 15 Jul 2022 21:37:38 +0000 +Subject: PCI: hv: Fix hv_arch_irq_unmask() for multi-MSI +To: +Cc: Jeffrey Hugo , , , , , , , , , , Michael Kelley , Wei Liu , Carl Vanderlip +Message-ID: <20220715213740.19693-3-quic_carlv@quicinc.com> + +From: Jeffrey Hugo + +commit 455880dfe292a2bdd3b4ad6a107299fce610e64b upstream. + +In the multi-MSI case, hv_arch_irq_unmask() will only operate on the first +MSI of the N allocated. This is because only the first msi_desc is cached +and it is shared by all the MSIs of the multi-MSI block. This means that +hv_arch_irq_unmask() gets the correct address, but the wrong data (always +0). + +This can break MSIs. + +Lets assume MSI0 is vector 34 on CPU0, and MSI1 is vector 33 on CPU0. + +hv_arch_irq_unmask() is called on MSI0. It uses a hypercall to configure +the MSI address and data (0) to vector 34 of CPU0. This is correct. Then +hv_arch_irq_unmask is called on MSI1. It uses another hypercall to +configure the MSI address and data (0) to vector 33 of CPU0. This is +wrong, and results in both MSI0 and MSI1 being routed to vector 33. Linux +will observe extra instances of MSI1 and no instances of MSI0 despite the +endpoint device behaving correctly. + +For the multi-MSI case, we need unique address and data info for each MSI, +but the cached msi_desc does not provide that. However, that information +can be gotten from the int_desc cached in the chip_data by +compose_msi_msg(). Fix the multi-MSI case to use that cached information +instead. Since hv_set_msi_entry_from_desc() is no longer applicable, +remove it. + +5.10 backport - removed unused hv_set_msi_entry_from_desc function from +mshyperv.h instead of pci-hyperv.c. msi_entry.address/data.as_uint32 +changed to direct reference (as they are u32's, just sans union). + +Signed-off-by: Jeffrey Hugo +Reviewed-by: Michael Kelley +Link: https://lore.kernel.org/r/1651068453-29588-1-git-send-email-quic_jhugo@quicinc.com +Signed-off-by: Wei Liu +Signed-off-by: Carl Vanderlip +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/mshyperv.h | 7 ------- + drivers/pci/controller/pci-hyperv.c | 5 ++++- + 2 files changed, 4 insertions(+), 8 deletions(-) + +--- a/arch/x86/include/asm/mshyperv.h ++++ b/arch/x86/include/asm/mshyperv.h +@@ -247,13 +247,6 @@ bool hv_vcpu_is_preempted(int vcpu); + static inline void hv_apic_init(void) {} + #endif + +-static inline void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry, +- struct msi_desc *msi_desc) +-{ +- msi_entry->address = msi_desc->msg.address_lo; +- msi_entry->data = msi_desc->msg.data; +-} +- + #else /* CONFIG_HYPERV */ + static inline void hyperv_init(void) {} + static inline void hyperv_setup_mmu_ops(void) {} +--- a/drivers/pci/controller/pci-hyperv.c ++++ b/drivers/pci/controller/pci-hyperv.c +@@ -1210,6 +1210,7 @@ static void hv_irq_unmask(struct irq_dat + struct msi_desc *msi_desc = irq_data_get_msi_desc(data); + struct irq_cfg *cfg = irqd_cfg(data); + struct hv_retarget_device_interrupt *params; ++ struct tran_int_desc *int_desc; + struct hv_pcibus_device *hbus; + struct cpumask *dest; + cpumask_var_t tmp; +@@ -1224,6 +1225,7 @@ static void hv_irq_unmask(struct irq_dat + pdev = msi_desc_to_pci_dev(msi_desc); + pbus = pdev->bus; + hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata); ++ int_desc = data->chip_data; + + spin_lock_irqsave(&hbus->retarget_msi_interrupt_lock, flags); + +@@ -1231,7 +1233,8 @@ static void hv_irq_unmask(struct irq_dat + memset(params, 0, sizeof(*params)); + params->partition_id = HV_PARTITION_ID_SELF; + params->int_entry.source = 1; /* MSI(-X) */ +- hv_set_msi_entry_from_desc(¶ms->int_entry.msi_entry, msi_desc); ++ params->int_entry.msi_entry.address = int_desc->address & 0xffffffff; ++ params->int_entry.msi_entry.data = int_desc->data; + params->device_id = (hbus->hdev->dev_instance.b[5] << 24) | + (hbus->hdev->dev_instance.b[4] << 16) | + (hbus->hdev->dev_instance.b[7] << 8) | diff --git a/queue-5.10/pci-hv-fix-interrupt-mapping-for-multi-msi.patch b/queue-5.10/pci-hv-fix-interrupt-mapping-for-multi-msi.patch new file mode 100644 index 00000000000..496d9c6180e --- /dev/null +++ b/queue-5.10/pci-hv-fix-interrupt-mapping-for-multi-msi.patch @@ -0,0 +1,186 @@ +From foo@baz Sat Jul 23 05:13:20 PM CEST 2022 +From: Carl Vanderlip +Date: Fri, 15 Jul 2022 21:37:40 +0000 +Subject: PCI: hv: Fix interrupt mapping for multi-MSI +To: +Cc: Jeffrey Hugo , , , , , , , , , , Michael Kelley , Wei Liu , Carl Vanderlip +Message-ID: <20220715213740.19693-5-quic_carlv@quicinc.com> + +From: Jeffrey Hugo + +commit a2bad844a67b1c7740bda63e87453baf63c3a7f7 upstream. + +According to Dexuan, the hypervisor folks beleive that multi-msi +allocations are not correct. compose_msi_msg() will allocate multi-msi +one by one. However, multi-msi is a block of related MSIs, with alignment +requirements. In order for the hypervisor to allocate properly aligned +and consecutive entries in the IOMMU Interrupt Remapping Table, there +should be a single mapping request that requests all of the multi-msi +vectors in one shot. + +Dexuan suggests detecting the multi-msi case and composing a single +request related to the first MSI. Then for the other MSIs in the same +block, use the cached information. This appears to be viable, so do it. + +5.10 backport - add hv_msi_get_int_vector helper function. Fixed merge +conflict due to delivery_mode name change (APIC_DELIVERY_MODE_FIXED +is the value given to dest_Fixed). Removed unused variable in +hv_compose_msi_msg. Fixed reference to msi_desc->pci to point to +the same is_msix variable. Removed changes to compose_msi_req_v3 since +it doesn't exist yet. + +Suggested-by: Dexuan Cui +Signed-off-by: Jeffrey Hugo +Reviewed-by: Dexuan Cui +Tested-by: Michael Kelley +Link: https://lore.kernel.org/r/1652282599-21643-1-git-send-email-quic_jhugo@quicinc.com +Signed-off-by: Wei Liu +Signed-off-by: Carl Vanderlip +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-hyperv.c | 61 +++++++++++++++++++++++++++++++----- + 1 file changed, 53 insertions(+), 8 deletions(-) + +--- a/drivers/pci/controller/pci-hyperv.c ++++ b/drivers/pci/controller/pci-hyperv.c +@@ -1118,6 +1118,10 @@ static void hv_int_desc_free(struct hv_p + u8 buffer[sizeof(struct pci_delete_interrupt)]; + } ctxt; + ++ if (!int_desc->vector_count) { ++ kfree(int_desc); ++ return; ++ } + memset(&ctxt, 0, sizeof(ctxt)); + int_pkt = (struct pci_delete_interrupt *)&ctxt.pkt.message; + int_pkt->message_type.type = +@@ -1180,6 +1184,13 @@ static void hv_irq_mask(struct irq_data + pci_msi_mask_irq(data); + } + ++static unsigned int hv_msi_get_int_vector(struct irq_data *data) ++{ ++ struct irq_cfg *cfg = irqd_cfg(data); ++ ++ return cfg->vector; ++} ++ + static int hv_msi_prepare(struct irq_domain *domain, struct device *dev, + int nvec, msi_alloc_info_t *info) + { +@@ -1335,12 +1346,12 @@ static void hv_pci_compose_compl(void *c + + static u32 hv_compose_msi_req_v1( + struct pci_create_interrupt *int_pkt, struct cpumask *affinity, +- u32 slot, u8 vector) ++ u32 slot, u8 vector, u8 vector_count) + { + int_pkt->message_type.type = PCI_CREATE_INTERRUPT_MESSAGE; + int_pkt->wslot.slot = slot; + int_pkt->int_desc.vector = vector; +- int_pkt->int_desc.vector_count = 1; ++ int_pkt->int_desc.vector_count = vector_count; + int_pkt->int_desc.delivery_mode = dest_Fixed; + + /* +@@ -1354,14 +1365,14 @@ static u32 hv_compose_msi_req_v1( + + static u32 hv_compose_msi_req_v2( + struct pci_create_interrupt2 *int_pkt, struct cpumask *affinity, +- u32 slot, u8 vector) ++ u32 slot, u8 vector, u8 vector_count) + { + int cpu; + + int_pkt->message_type.type = PCI_CREATE_INTERRUPT_MESSAGE2; + int_pkt->wslot.slot = slot; + int_pkt->int_desc.vector = vector; +- int_pkt->int_desc.vector_count = 1; ++ int_pkt->int_desc.vector_count = vector_count; + int_pkt->int_desc.delivery_mode = dest_Fixed; + + /* +@@ -1389,7 +1400,6 @@ static u32 hv_compose_msi_req_v2( + */ + static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) + { +- struct irq_cfg *cfg = irqd_cfg(data); + struct hv_pcibus_device *hbus; + struct vmbus_channel *channel; + struct hv_pci_dev *hpdev; +@@ -1398,6 +1408,8 @@ static void hv_compose_msi_msg(struct ir + struct cpumask *dest; + struct compose_comp_ctxt comp; + struct tran_int_desc *int_desc; ++ struct msi_desc *msi_desc; ++ u8 vector, vector_count; + struct { + struct pci_packet pci_pkt; + union { +@@ -1418,7 +1430,8 @@ static void hv_compose_msi_msg(struct ir + return; + } + +- pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data)); ++ msi_desc = irq_data_get_msi_desc(data); ++ pdev = msi_desc_to_pci_dev(msi_desc); + dest = irq_data_get_effective_affinity_mask(data); + pbus = pdev->bus; + hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata); +@@ -1431,6 +1444,36 @@ static void hv_compose_msi_msg(struct ir + if (!int_desc) + goto drop_reference; + ++ if (!msi_desc->msi_attrib.is_msix && msi_desc->nvec_used > 1) { ++ /* ++ * If this is not the first MSI of Multi MSI, we already have ++ * a mapping. Can exit early. ++ */ ++ if (msi_desc->irq != data->irq) { ++ data->chip_data = int_desc; ++ int_desc->address = msi_desc->msg.address_lo | ++ (u64)msi_desc->msg.address_hi << 32; ++ int_desc->data = msi_desc->msg.data + ++ (data->irq - msi_desc->irq); ++ msg->address_hi = msi_desc->msg.address_hi; ++ msg->address_lo = msi_desc->msg.address_lo; ++ msg->data = int_desc->data; ++ put_pcichild(hpdev); ++ return; ++ } ++ /* ++ * The vector we select here is a dummy value. The correct ++ * value gets sent to the hypervisor in unmask(). This needs ++ * to be aligned with the count, and also not zero. Multi-msi ++ * is powers of 2 up to 32, so 32 will always work here. ++ */ ++ vector = 32; ++ vector_count = msi_desc->nvec_used; ++ } else { ++ vector = hv_msi_get_int_vector(data); ++ vector_count = 1; ++ } ++ + memset(&ctxt, 0, sizeof(ctxt)); + init_completion(&comp.comp_pkt.host_event); + ctxt.pci_pkt.completion_func = hv_pci_compose_compl; +@@ -1441,7 +1484,8 @@ static void hv_compose_msi_msg(struct ir + size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1, + dest, + hpdev->desc.win_slot.slot, +- cfg->vector); ++ vector, ++ vector_count); + break; + + case PCI_PROTOCOL_VERSION_1_2: +@@ -1449,7 +1493,8 @@ static void hv_compose_msi_msg(struct ir + size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2, + dest, + hpdev->desc.win_slot.slot, +- cfg->vector); ++ vector, ++ vector_count); + break; + + default: diff --git a/queue-5.10/pci-hv-fix-multi-msi-to-allow-more-than-one-msi-vector.patch b/queue-5.10/pci-hv-fix-multi-msi-to-allow-more-than-one-msi-vector.patch new file mode 100644 index 00000000000..20567155e07 --- /dev/null +++ b/queue-5.10/pci-hv-fix-multi-msi-to-allow-more-than-one-msi-vector.patch @@ -0,0 +1,77 @@ +From foo@baz Sat Jul 23 05:13:20 PM CEST 2022 +From: Carl Vanderlip +Date: Fri, 15 Jul 2022 21:37:37 +0000 +Subject: PCI: hv: Fix multi-MSI to allow more than one MSI vector +To: +Cc: Jeffrey Hugo , , , , , , , , , , Wei Liu , "Carl Vanderlip" +Message-ID: <20220715213740.19693-2-quic_carlv@quicinc.com> + +From: Jeffrey Hugo + +commit 08e61e861a0e47e5e1a3fb78406afd6b0cea6b6d upstream. + +If the allocation of multiple MSI vectors for multi-MSI fails in the core +PCI framework, the framework will retry the allocation as a single MSI +vector, assuming that meets the min_vecs specified by the requesting +driver. + +Hyper-V advertises that multi-MSI is supported, but reuses the VECTOR +domain to implement that for x86. The VECTOR domain does not support +multi-MSI, so the alloc will always fail and fallback to a single MSI +allocation. + +In short, Hyper-V advertises a capability it does not implement. + +Hyper-V can support multi-MSI because it coordinates with the hypervisor +to map the MSIs in the IOMMU's interrupt remapper, which is something the +VECTOR domain does not have. Therefore the fix is simple - copy what the +x86 IOMMU drivers (AMD/Intel-IR) do by removing +X86_IRQ_ALLOC_CONTIGUOUS_VECTORS after calling the VECTOR domain's +pci_msi_prepare(). + +5.10 backport - adds the hv_msi_prepare wrapper function + +Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") +Signed-off-by: Jeffrey Hugo +Reviewed-by: Dexuan Cui +Link: https://lore.kernel.org/r/1649856981-14649-1-git-send-email-quic_jhugo@quicinc.com +Signed-off-by: Wei Liu +Signed-off-by: Carl Vanderlip +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-hyperv.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +--- a/drivers/pci/controller/pci-hyperv.c ++++ b/drivers/pci/controller/pci-hyperv.c +@@ -1180,6 +1180,21 @@ static void hv_irq_mask(struct irq_data + pci_msi_mask_irq(data); + } + ++static int hv_msi_prepare(struct irq_domain *domain, struct device *dev, ++ int nvec, msi_alloc_info_t *info) ++{ ++ int ret = pci_msi_prepare(domain, dev, nvec, info); ++ ++ /* ++ * By using the interrupt remapper in the hypervisor IOMMU, contiguous ++ * CPU vectors is not needed for multi-MSI ++ */ ++ if (info->type == X86_IRQ_ALLOC_TYPE_PCI_MSI) ++ info->flags &= ~X86_IRQ_ALLOC_CONTIGUOUS_VECTORS; ++ ++ return ret; ++} ++ + /** + * hv_irq_unmask() - "Unmask" the IRQ by setting its current + * affinity. +@@ -1545,7 +1560,7 @@ static struct irq_chip hv_msi_irq_chip = + }; + + static struct msi_domain_ops hv_msi_ops = { +- .msi_prepare = pci_msi_prepare, ++ .msi_prepare = hv_msi_prepare, + .msi_free = hv_msi_free, + }; + diff --git a/queue-5.10/pci-hv-reuse-existing-irte-allocation-in-compose_msi_msg.patch b/queue-5.10/pci-hv-reuse-existing-irte-allocation-in-compose_msi_msg.patch new file mode 100644 index 00000000000..50bd88a4ca9 --- /dev/null +++ b/queue-5.10/pci-hv-reuse-existing-irte-allocation-in-compose_msi_msg.patch @@ -0,0 +1,69 @@ +From foo@baz Sat Jul 23 05:13:20 PM CEST 2022 +From: Carl Vanderlip +Date: Fri, 15 Jul 2022 21:37:39 +0000 +Subject: PCI: hv: Reuse existing IRTE allocation in compose_msi_msg() +To: +Cc: Jeffrey Hugo , , , , , , , , , , Michael Kelley , Wei Liu , Carl Vanderlip +Message-ID: <20220715213740.19693-4-quic_carlv@quicinc.com> + +From: Jeffrey Hugo + +commit b4b77778ecc5bfbd4e77de1b2fd5c1dd3c655f1f upstream. + +Currently if compose_msi_msg() is called multiple times, it will free any +previous IRTE allocation, and generate a new allocation. While nothing +prevents this from occurring, it is extraneous when Linux could just reuse +the existing allocation and avoid a bunch of overhead. + +However, when future IRTE allocations operate on blocks of MSIs instead of +a single line, freeing the allocation will impact all of the lines. This +could cause an issue where an allocation of N MSIs occurs, then some of +the lines are retargeted, and finally the allocation is freed/reallocated. +The freeing of the allocation removes all of the configuration for the +entire block, which requires all the lines to be retargeted, which might +not happen since some lines might already be unmasked/active. + +Signed-off-by: Jeffrey Hugo +Reviewed-by: Dexuan Cui +Tested-by: Dexuan Cui +Tested-by: Michael Kelley +Link: https://lore.kernel.org/r/1652282582-21595-1-git-send-email-quic_jhugo@quicinc.com +Signed-off-by: Wei Liu +Signed-off-by: Carl Vanderlip +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-hyperv.c | 16 +++++++++------- + 1 file changed, 9 insertions(+), 7 deletions(-) + +--- a/drivers/pci/controller/pci-hyperv.c ++++ b/drivers/pci/controller/pci-hyperv.c +@@ -1409,6 +1409,15 @@ static void hv_compose_msi_msg(struct ir + u32 size; + int ret; + ++ /* Reuse the previous allocation */ ++ if (data->chip_data) { ++ int_desc = data->chip_data; ++ msg->address_hi = int_desc->address >> 32; ++ msg->address_lo = int_desc->address & 0xffffffff; ++ msg->data = int_desc->data; ++ return; ++ } ++ + pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data)); + dest = irq_data_get_effective_affinity_mask(data); + pbus = pdev->bus; +@@ -1418,13 +1427,6 @@ static void hv_compose_msi_msg(struct ir + if (!hpdev) + goto return_null_message; + +- /* Free any previous message that might have already been composed. */ +- if (data->chip_data) { +- int_desc = data->chip_data; +- data->chip_data = NULL; +- hv_int_desc_free(hpdev, int_desc); +- } +- + int_desc = kzalloc(sizeof(*int_desc), GFP_ATOMIC); + if (!int_desc) + goto drop_reference; diff --git a/queue-5.10/series b/queue-5.10/series index e7bfbb22f8f..027ac9edcbb 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -14,3 +14,7 @@ net-inline-rollback_registered.patch net-move-rollback_registered_many.patch net-inline-rollback_registered_many.patch revert-m68knommu-only-set-config_isa_dma_api-for-coldfire-sub-arch.patch +pci-hv-fix-multi-msi-to-allow-more-than-one-msi-vector.patch +pci-hv-fix-hv_arch_irq_unmask-for-multi-msi.patch +pci-hv-reuse-existing-irte-allocation-in-compose_msi_msg.patch +pci-hv-fix-interrupt-mapping-for-multi-msi.patch