linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: pci-usb/pci-sata broken with LPAE config after "reduce use of block bounce buffers"
Date: Thu, 2 Apr 2020 17:31:32 +0530	[thread overview]
Message-ID: <c832540a-802a-e361-758d-67f387ae37a5@ti.com> (raw)
In-Reply-To: <a7d920ab-b681-45bc-677b-3db76e96cf7c@ti.com>

Hi Christoph,

On 2/18/2020 5:45 PM, Kishon Vijay Abraham I wrote:
> Christoph,
> 
> On 17/02/20 7:53 pm, Christoph Hellwig wrote:
>> On Wed, Feb 05, 2020 at 05:05:42PM +0100, Christoph Hellwig wrote:
>>> On Wed, Feb 05, 2020 at 03:03:13PM +0530, Kishon Vijay Abraham I wrote:
>>>> Yes, I see the mismatch after reverting the above patches.
>>>
>>> In which case the data mismatch is very likely due to a different root
>>> cause.
>>
>> Did you manage to dig into this a little more?
> 
> I'll probably get to this later half of this week. Will update you then.
> 

Sorry for the delay in getting back to this. But I guess I have root caused the
issue now.

The issue was because NVMe is requesting a sector size (4096KB) which is more
than what is supported by SWIOTLB default (256KB). NVMe driver actually has a
mechanism to select the correct sector size

 dev->ctrl.max_hw_sectors = min_t(u32,
                NVME_MAX_KB_SZ << 1, dma_max_mapping_size(dev->dev) >> 9);
However dma_max_mapping_size() here misbehaves and gives 4G. Ideally it should
have given 256KB -> the max supported by SWIOTLB

Tracing through the dma_max_mapping_size(), dma_direct_max_mapping_size() was
giving incorrect value

size_t dma_direct_max_mapping_size(struct device *dev)
{
        /* If SWIOTLB is active, use its maximum mapping size */
        if (is_swiotlb_active() &&
            (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
                return swiotlb_max_mapping_size(dev);
        return SIZE_MAX;
}
In the above function swiotlb_max_mapping_size(dev) gives 256KB however
dma_addressing_limited(dev) always returns false. So 256KB is never returned to
the NVMe driver.

Tracing dma_addressing_limited(dev), found a bug in
dma_direct_get_required_mask(). When it passes the physical address to
phys_to_dma_direct(), the upper 32 bit is lost and dma_addressing_limited(dev)
thinks the entire address is accessible by the device.

A patch that type casts the argument of phys_to_dma_direct() like below fixes
the issue.

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 32ec69cdba54..0081410334c8 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -51,7 +51,9 @@ static inline struct page *dma_direct_to_page(struct device
*dev, u64 dma_direct_get_required_mask(struct device *dev)
 {
-       u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
+       u64 max_dma =
+               phys_to_dma_direct(dev,
+                                  (phys_addr_t)(max_pfn - 1) << PAGE_SHIFT);
        return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
 }

If this looks okay to you, I can post a patch for it.

Thanks
Kishon

      reply	other threads:[~2020-04-02 12:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15 10:59 pci-usb/pci-sata broken with LPAE config after "reduce use of block bounce buffers" Kishon Vijay Abraham I
2019-11-15 13:06 ` Christoph Hellwig
2019-11-15 14:18   ` Kishon Vijay Abraham I
2019-11-16 16:35     ` Christoph Hellwig
2019-11-18 17:21       ` Robin Murphy
2019-11-25  5:43         ` Kishon Vijay Abraham I
2020-01-27 13:10           ` Kishon Vijay Abraham I
2020-01-27 13:22             ` Robin Murphy
2020-01-29  6:24               ` Kishon Vijay Abraham I
2020-01-30  7:58 ` Christoph Hellwig
2020-01-30  8:09   ` Kishon Vijay Abraham I
2020-01-30 16:42     ` Christoph Hellwig
2020-01-31 11:44       ` Kishon Vijay Abraham I
2020-02-03 14:21         ` Christoph Hellwig
2020-02-05  5:15           ` Kishon Vijay Abraham I
2020-02-05  7:47             ` Christoph Hellwig
2020-02-05  8:32               ` Kishon Vijay Abraham I
2020-02-05  8:48                 ` Christoph Hellwig
2020-02-05  9:18                   ` Kishon Vijay Abraham I
2020-02-05  9:19                     ` Christoph Hellwig
2020-02-05  9:33                       ` Kishon Vijay Abraham I
2020-02-05 16:05                         ` Christoph Hellwig
2020-02-17 14:23                           ` Christoph Hellwig
2020-02-18 12:15                             ` Kishon Vijay Abraham I
2020-04-02 12:01                               ` Kishon Vijay Abraham I [this message]

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=c832540a-802a-e361-758d-67f387ae37a5@ti.com \
    --to=kishon@ti.com \
    --cc=hch@lst.de \
    --cc=linux-pci@vger.kernel.org \
    /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).