All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Alan Mikhak <alanmikhak@gmail.com>
Cc: gustavo.pimentel@synopsys.com, 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, 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: Fri, 22 May 2020 15:04:07 +0100	[thread overview]
Message-ID: <20200522140406.GH11785@e121166-lin.cambridge.arm.com> (raw)
In-Reply-To: <20200520023304.14348-1-amikhak@wirelessfabric.com>

On Tue, May 19, 2020 at 07:33:04PM -0700, Alan Mikhak wrote:
> 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.

You did the right thing (and you helped me unearth some major
deficiencies in current DWC code). Unfortunately I have to drop:

9e73fa02aa00 ("PCI: dwc: Warn if MEM resource size exceeds max for 32-bits")

because it triggers regressions (and it is still not in the mainline,
IMO there would be more if we send it upstream).

I will keep:

e1fc129219a8 ("PCI: dwc: Program outbound ATU upper limit register")

because it is a step in the right direction and makes sense on its own.

Thanks for all the effort you put into this.

Lorenzo

> Regards,
> Alan
> 
> 
> 
> 
> 
> 

  reply	other threads:[~2020-05-22 14:04 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
2020-05-22 14:04             ` Lorenzo Pieralisi [this message]
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=20200522140406.GH11785@e121166-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=alan.mikhak@sifive.com \
    --cc=alanmikhak@gmail.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=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.