linux-hyperv.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Sagi Grimberg <sagi@grimberg.me>,
	Max Gurtovoy <maxg@mellanox.com>,
	Bart Van Assche <bvanassche@acm.org>,
	linux-rdma@vger.kernel.org, linux-scsi@vger.kernel.org,
	megaraidlinux.pdl@broadcom.com, MPT-FusionLinux.pdl@broadcom.com,
	linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: properly communicate queue limits to the DMA layer v2
Date: Mon, 17 Jun 2019 14:19:52 +0200	[thread overview]
Message-ID: <20190617122000.22181-1-hch@lst.de> (raw)

Hi Martin,

we've always had a bit of a problem communicating the block layer
queue limits to the DMA layer, which needs to respect them when
an IOMMU that could merge segments is used.  Unfortunately most
drivers don't get this right.  Oddly enough we've been mostly
getting away with it, although lately dma-debug has been catching
a few of those issues.

The segment merging fix for devices with PRP-like structures seems
to have escalated this a bit.  The first patch fixes the actual
report from Sebastian, while the rest fix every drivers that appears
to have the problem based on a code audit looking for drivers using
blk_queue_max_segment_size, blk_queue_segment_boundary or
blk_queue_virt_boundary and calling dma_map_sg eventually.

For SCSI drivers I've taken the blk_queue_virt_boundary setting
to the SCSI core, similar to how we did it for the other two settings
a while ago.  This also deals with the fact that the DMA layer
settings are on a per-device granularity, so the per-device settings
in a few SCSI drivers can't actually work in an IOMMU environment.

It would be nice to eventually pass these limits as arguments to
dma_map_sg, but that is a far too big series for the 5.2 merge
window.

Changes since v1:
 - dropped block layer parts merged by Jens
 - dropped the usb-storage / uas changes, as the virt_boundary usage
   there will be dropped soon
 - reworked the mpt3sas / megaraid_sas changes to keep per-device
   settings

             reply	other threads:[~2019-06-17 12:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 12:19 Christoph Hellwig [this message]
2019-06-17 12:19 ` [PATCH 1/8] scsi: add a host / host template field for the virt boundary Christoph Hellwig
2019-06-17 20:51   ` Bart Van Assche
2019-06-18  0:35   ` Ming Lei
2019-06-20  6:17     ` Kashyap Desai
2019-06-17 12:19 ` [PATCH 2/8] scsi: take the DMA max mapping size into account Christoph Hellwig
2019-06-17 20:56   ` Bart Van Assche
2019-07-22  6:00     ` Ming Lei
2019-07-22  6:18       ` Dexuan-Linux Cui
2019-07-22  7:40       ` Damien Le Moal
2019-06-17 12:19 ` [PATCH 3/8] ufshcd: set max_segment_size in the scsi host template Christoph Hellwig
2019-06-17 20:58   ` Bart Van Assche
2019-06-17 12:19 ` [PATCH 4/8] storvsc: set virt_boundary_mask " Christoph Hellwig
2019-06-17 20:59   ` Bart Van Assche
2019-06-17 12:19 ` [PATCH 5/8] IB/iser: set virt_boundary_mask in the scsi host Christoph Hellwig
2019-06-17 17:34   ` Sagi Grimberg
2019-06-24 22:32   ` Max Gurtovoy
2019-06-17 12:19 ` [PATCH 6/8] IB/srp: " Christoph Hellwig
2019-06-17 17:35   ` Sagi Grimberg
2019-06-17 21:01   ` Bart Van Assche
2019-06-24 22:33   ` Max Gurtovoy
2019-06-17 12:19 ` [PATCH 7/8] mpt3sas: set an unlimited max_segment_size for SAS 3.0 HBAs Christoph Hellwig
2019-06-18  0:46   ` Ming Lei
2019-06-20  7:04     ` Suganath Prabu Subramani
2019-06-20  7:08       ` Suganath Prabu Subramani
2019-06-17 12:20 ` [PATCH 8/8] megaraid_sas: set an unlimited max_segment_size Christoph Hellwig
2019-07-15 16:58 ` properly communicate queue limits to the DMA layer v2 Christoph Hellwig
2019-07-15 17:33   ` Martin K. Petersen
2019-07-15 17:46     ` Christoph Hellwig
2019-07-17  3:07       ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190617122000.22181-1-hch@lst.de \
    --to=hch@lst.de \
    --cc=MPT-FusionLinux.pdl@broadcom.com \
    --cc=bvanassche@acm.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=maxg@mellanox.com \
    --cc=megaraidlinux.pdl@broadcom.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).