Patch "IB/mlx5: Use __iowrite64_copy() for write combining stores" has been added to the 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    IB/mlx5: Use __iowrite64_copy() for write combining stores

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     ib-mlx5-use-__iowrite64_copy-for-write-combining-sto.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 21cfa1defe61d9325d8db6efd0afd1b83372439d
Author: Jason Gunthorpe <jgg@xxxxxxxx>
Date:   Thu Apr 11 13:46:19 2024 -0300

    IB/mlx5: Use __iowrite64_copy() for write combining stores
    
    [ Upstream commit ef302283ddfceaba2657923af3f90fd58e6dff06 ]
    
    mlx5 has a built in self-test at driver startup to evaluate if the
    platform supports write combining to generate a 64 byte PCIe TLP or
    not. This has proven necessary because a lot of common scenarios end up
    with broken write combining (especially inside virtual machines) and there
    is other way to learn this information.
    
    This self test has been consistently failing on new ARM64 CPU
    designs (specifically with NVIDIA Grace's implementation of Neoverse
    V2). The C loop around writeq() generates some pretty terrible ARM64
    assembly, but historically this has worked on a lot of existing ARM64 CPUs
    till now.
    
    We see it succeed about 1 time in 10,000 on the worst effected
    systems. The CPU architects speculate that the load instructions
    interspersed with the stores makes the WC buffers statistically flush too
    often and thus the generation of large TLPs becomes infrequent. This makes
    the boot up test unreliable in that it indicates no write-combining,
    however userspace would be fine since it uses a ST4 instruction.
    
    Further, S390 has similar issues where only the special zpci_memcpy_toio()
    will actually generate large TLPs, and the open coded loop does not
    trigger it at all.
    
    Fix both ARM64 and S390 by switching to __iowrite64_copy() which now
    provides architecture specific variants that have a high change of
    generating a large TLP with write combining. x86 continues to use a
    similar writeq loop in the generate __iowrite64_copy().
    
    Fixes: 11f552e21755 ("IB/mlx5: Test write combining support")
    Link: https://lore.kernel.org/r/6-v3-1893cd8b9369+1925-mlx5_arm_wc_jgg@xxxxxxxxxx
    Tested-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
    Acked-by: Leon Romanovsky <leonro@xxxxxxxxxx>
    Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/infiniband/hw/mlx5/mem.c b/drivers/infiniband/hw/mlx5/mem.c
index 96ffbbaf0a73d..5a22be14d958f 100644
--- a/drivers/infiniband/hw/mlx5/mem.c
+++ b/drivers/infiniband/hw/mlx5/mem.c
@@ -30,6 +30,7 @@
  * SOFTWARE.
  */
 
+#include <linux/io.h>
 #include <rdma/ib_umem_odp.h>
 #include "mlx5_ib.h"
 #include <linux/jiffies.h>
@@ -108,7 +109,6 @@ static int post_send_nop(struct mlx5_ib_dev *dev, struct ib_qp *ibqp, u64 wr_id,
 	__be32 mmio_wqe[16] = {};
 	unsigned long flags;
 	unsigned int idx;
-	int i;
 
 	if (unlikely(dev->mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR))
 		return -EIO;
@@ -148,10 +148,8 @@ static int post_send_nop(struct mlx5_ib_dev *dev, struct ib_qp *ibqp, u64 wr_id,
 	 * we hit doorbell
 	 */
 	wmb();
-	for (i = 0; i < 8; i++)
-		mlx5_write64(&mmio_wqe[i * 2],
-			     bf->bfreg->map + bf->offset + i * 8);
-	io_stop_wc();
+	__iowrite64_copy(bf->bfreg->map + bf->offset, mmio_wqe,
+			 sizeof(mmio_wqe) / 8);
 
 	bf->offset ^= bf->buf_size;
 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux