--- /dev/null
+From foo@baz Sat Jul 23 05:11:49 PM CEST 2022
+From: Carl Vanderlip <quic_carlv@quicinc.com>
+Date: Mon, 18 Jul 2022 15:20:30 +0000
+Subject: PCI: hv: Fix hv_arch_irq_unmask() for multi-MSI
+To: <stable@vger.kernel.org>
+Cc: Jeffrey Hugo <quic_jhugo@quicinc.com>, <kys@microsoft.com>, <haiyangz@microsoft.com>, <sthemmin@microsoft.com>, <wei.liu@microsoft.com>, <decui@microsoft.com>, <lorenzo.pieralisi@arm.com>, <robh@kernel.org>, <kw@linux.com>, <bhelgaas@google.com>, Michael Kelley <mikelley@microsoft.com>, Wei Liu <wei.liu@kernel.org>, Carl Vanderlip <quic_carlv@quicinc.com>
+Message-ID: <20220718152032.4675-3-quic_carlv@quicinc.com>
+
+From: Jeffrey Hugo <quic_jhugo@quicinc.com>
+
+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.15 backport - no changes to code, but merge conflict due to refactor.
+
+Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/1651068453-29588-1-git-send-email-quic_jhugo@quicinc.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -176,13 +176,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.as_uint32 = msi_desc->msg.address_lo;
+- msi_entry->data.as_uint32 = msi_desc->msg.data;
+-}
+-
+ struct irq_domain *hv_create_pci_msi_domain(void);
+
+ int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int vector,
+--- a/drivers/pci/controller/pci-hyperv.c
++++ b/drivers/pci/controller/pci-hyperv.c
+@@ -1234,6 +1234,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;
+@@ -1248,6 +1249,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);
+
+@@ -1255,7 +1257,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 = HV_INTERRUPT_SOURCE_MSI;
+- hv_set_msi_entry_from_desc(¶ms->int_entry.msi_entry, msi_desc);
++ params->int_entry.msi_entry.address.as_uint32 = int_desc->address & 0xffffffff;
++ params->int_entry.msi_entry.data.as_uint32 = 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) |
--- /dev/null
+From foo@baz Sat Jul 23 05:11:49 PM CEST 2022
+From: Carl Vanderlip <quic_carlv@quicinc.com>
+Date: Mon, 18 Jul 2022 15:20:32 +0000
+Subject: PCI: hv: Fix interrupt mapping for multi-MSI
+To: <stable@vger.kernel.org>
+Cc: Jeffrey Hugo <quic_jhugo@quicinc.com>, <kys@microsoft.com>, <haiyangz@microsoft.com>, <sthemmin@microsoft.com>, <wei.liu@microsoft.com>, <decui@microsoft.com>, <lorenzo.pieralisi@arm.com>, <robh@kernel.org>, <kw@linux.com>, <bhelgaas@google.com>, Michael Kelley <mikelley@microsoft.com>, Wei Liu <wei.liu@kernel.org>, Carl Vanderlip <quic_carlv@quicinc.com>
+Message-ID: <20220718152032.4675-5-quic_carlv@quicinc.com>
+
+From: Jeffrey Hugo <quic_jhugo@quicinc.com>
+
+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.15 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 DELIVERY_MODE on x86). Removed unused variable
+in hv_compose_msi_msg. Fixed reference to msi_desc->pci to point to
+the same is_msix variable.
+
+Suggested-by: Dexuan Cui <decui@microsoft.com>
+Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Tested-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/1652282599-21643-1-git-send-email-quic_jhugo@quicinc.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/pci-hyperv.c | 68 ++++++++++++++++++++++++++++++------
+ 1 file changed, 57 insertions(+), 11 deletions(-)
+
+--- a/drivers/pci/controller/pci-hyperv.c
++++ b/drivers/pci/controller/pci-hyperv.c
+@@ -1142,6 +1142,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 =
+@@ -1204,6 +1208,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)
+ {
+@@ -1359,12 +1370,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 = APIC_DELIVERY_MODE_FIXED;
+
+ /*
+@@ -1387,14 +1398,14 @@ static int hv_compose_msi_req_get_cpu(st
+
+ 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 = APIC_DELIVERY_MODE_FIXED;
+ cpu = hv_compose_msi_req_get_cpu(affinity);
+ int_pkt->int_desc.processor_array[0] =
+@@ -1406,7 +1417,7 @@ static u32 hv_compose_msi_req_v2(
+
+ static u32 hv_compose_msi_req_v3(
+ struct pci_create_interrupt3 *int_pkt, struct cpumask *affinity,
+- u32 slot, u32 vector)
++ u32 slot, u32 vector, u8 vector_count)
+ {
+ int cpu;
+
+@@ -1414,7 +1425,7 @@ static u32 hv_compose_msi_req_v3(
+ int_pkt->wslot.slot = slot;
+ int_pkt->int_desc.vector = vector;
+ int_pkt->int_desc.reserved = 0;
+- int_pkt->int_desc.vector_count = 1;
++ int_pkt->int_desc.vector_count = vector_count;
+ int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+ cpu = hv_compose_msi_req_get_cpu(affinity);
+ int_pkt->int_desc.processor_array[0] =
+@@ -1437,7 +1448,6 @@ static u32 hv_compose_msi_req_v3(
+ */
+ 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;
+@@ -1446,6 +1456,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 {
+@@ -1467,7 +1479,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);
+@@ -1480,6 +1493,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;
+@@ -1490,7 +1533,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:
+@@ -1498,14 +1542,16 @@ 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;
+
+ case PCI_PROTOCOL_VERSION_1_4:
+ size = hv_compose_msi_req_v3(&ctxt.int_pkts.v3,
+ dest,
+ hpdev->desc.win_slot.slot,
+- cfg->vector);
++ vector,
++ vector_count);
+ break;
+
+ default:
--- /dev/null
+From foo@baz Sat Jul 23 05:11:49 PM CEST 2022
+From: Carl Vanderlip <quic_carlv@quicinc.com>
+Date: Mon, 18 Jul 2022 15:20:29 +0000
+Subject: PCI: hv: Fix multi-MSI to allow more than one MSI vector
+To: <stable@vger.kernel.org>
+Cc: Jeffrey Hugo <quic_jhugo@quicinc.com>, <kys@microsoft.com>, <haiyangz@microsoft.com>, <sthemmin@microsoft.com>, <wei.liu@microsoft.com>, <decui@microsoft.com>, <lorenzo.pieralisi@arm.com>, <robh@kernel.org>, <kw@linux.com>, <bhelgaas@google.com>, Wei Liu <wei.liu@kernel.org>, "Carl Vanderlip" <quic_carlv@quicinc.com>
+Message-ID: <20220718152032.4675-2-quic_carlv@quicinc.com>
+
+From: Jeffrey Hugo <quic_jhugo@quicinc.com>
+
+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.15 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 <quic_jhugo@quicinc.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Link: https://lore.kernel.org/r/1649856981-14649-1-git-send-email-quic_jhugo@quicinc.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -1204,6 +1204,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.
+@@ -1601,7 +1616,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,
+ };
+
--- /dev/null
+From foo@baz Sat Jul 23 05:11:49 PM CEST 2022
+From: Carl Vanderlip <quic_carlv@quicinc.com>
+Date: Mon, 18 Jul 2022 15:20:31 +0000
+Subject: PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()
+To: <stable@vger.kernel.org>
+Cc: Jeffrey Hugo <quic_jhugo@quicinc.com>, <kys@microsoft.com>, <haiyangz@microsoft.com>, <sthemmin@microsoft.com>, <wei.liu@microsoft.com>, <decui@microsoft.com>, <lorenzo.pieralisi@arm.com>, <robh@kernel.org>, <kw@linux.com>, <bhelgaas@google.com>, Michael Kelley <mikelley@microsoft.com>, Wei Liu <wei.liu@kernel.org>, Carl Vanderlip <quic_carlv@quicinc.com>
+Message-ID: <20220718152032.4675-4-quic_carlv@quicinc.com>
+
+From: Jeffrey Hugo <quic_jhugo@quicinc.com>
+
+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 <quic_jhugo@quicinc.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Tested-by: Dexuan Cui <decui@microsoft.com>
+Tested-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/1652282582-21595-1-git-send-email-quic_jhugo@quicinc.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -1458,6 +1458,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;
+@@ -1467,13 +1476,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;
bus-mhi-host-pci_generic-add-telit-fn990.patch
revert-selftest-vm-verify-remap-destination-address-in-mremap_test.patch
revert-selftest-vm-verify-mmap-addr-in-mremap_test.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
projects / thirdparty / kernel / stable-queue.git / commitdiff
