All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Mikhak <alanmikhak@gmail.com>
To: gustavo.pimentel@synopsys.com
Cc: alan.mikhak@sifive.com, amurray@thegoodpenguin.co.uk,
	bhelgaas@google.com, helgaas@kernel.org, jingoohan1@gmail.com,
	jonathanh@nvidia.com, kthota@nvidia.com,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	lorenzo.pieralisi@arm.com, mmaddireddy@nvidia.com,
	sagar.tv@gmail.com, thierry.reding@gmail.com, vidyas@nvidia.com,
	Alan Mikhak <amikhak@wirelessfabric.com>
Subject: Re: PCI: dwc: Warn only for non-prefetchable memory resource size >4GB
Date: Tue, 19 May 2020 19:33:04 -0700	[thread overview]
Message-ID: <20200520023304.14348-1-amikhak@wirelessfabric.com> (raw)
In-Reply-To: <DM5PR12MB1276C836FEE46B113112FA92DAB90@DM5PR12MB1276.namprd12.prod.outlook.com>

Hi Lorenzo,

I came across this issue when implementing a Linux NVMe endpoint function
driver under the Linux PCI Endpoint Framework:
https://lwn.net/Articles/804369/

I needed to map up to 128GB of host memory using a single ATU window
from the endpoint side because NVMe PRPs can be scattered all over host
memory. In the process, I came across this 4GB limitation where the
maximum size of memory that can be mapped is limited by what a u32 value
can represent.

I submitted a separate patch to fix an undefined behavior that may also
happen in dw_pcie_prog_outbound_atu_unroll() under some circumstances
when the size of the memory being mapped is greater than what a u32 value
can represent.
https://patchwork.kernel.org/patch/11469701/

The above patch has been accepted. However, the variable pp->mem_size
in dw_pcie_host_init() is still a u32 whereas the value returned by
resource_size() is u64. If the resource size has non-zero upper 32-bits,
those upper 32-bits will be lost when assigning:
 pp->mem_size = resource_size(pp->mem).

Since current callers seem happy with the existing 4GB implementation
and fixing the u32 limit is beyond my available resources and has a long
high-impact tail, a warning seemed to be a good choice to highlight
this issue in case someone else decides to map a MEM region that is
greater than 4GB.

Removing the warning will avoid such discussions. Without this warning,
this limitation will go unnoticed and will only impact whoever has to
deal with it. It cost me time to figure it out when I had an application
that needed a region larger than 4GB. I figured the most I could do about
it is to raise the issue by adding a warning.

Regards,
Alan







  reply	other threads:[~2020-05-20  2:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 19:08 [PATCH] PCI: dwc: Warn only for non-prefetchable memory resource size >4GB Vidya Sagar
2020-05-13 22:35 ` Bjorn Helgaas
2020-05-18 15:54   ` Lorenzo Pieralisi
2020-05-19 13:55     ` Vidya Sagar
2020-05-19 14:58       ` Lorenzo Pieralisi
2020-05-19 17:08         ` Vidya Sagar
2020-05-19 18:20           ` Lorenzo Pieralisi
2020-05-19 22:08         ` Gustavo Pimentel
2020-05-20  2:33           ` Alan Mikhak [this message]
2020-05-22 14:04             ` Lorenzo Pieralisi
2020-05-20 11:06           ` [PATCH] " Lorenzo Pieralisi
2020-05-20 13:16             ` Thierry Reding
2020-05-20 17:51               ` Vidya Sagar
2020-05-20 11:17           ` Thierry Reding
2020-05-20 17:46             ` Vidya Sagar
2020-05-20 22:48               ` Rob Herring
2020-05-22 12:06                 ` Thierry Reding
2020-05-22 13:32                   ` Lorenzo Pieralisi
2020-05-22 14:06                     ` Thierry Reding
2020-05-23 17:30                       ` Vidya Sagar
2020-06-02 10:13                         ` Vidya Sagar

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=20200520023304.14348-1-amikhak@wirelessfabric.com \
    --to=alanmikhak@gmail.com \
    --cc=alan.mikhak@sifive.com \
    --cc=amikhak@wirelessfabric.com \
    --cc=amurray@thegoodpenguin.co.uk \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=helgaas@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=sagar.tv@gmail.com \
    --cc=thierry.reding@gmail.com \
    --cc=vidyas@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.