linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Vidya Sagar <vidyas@nvidia.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	Andrew Murray <amurray@thegoodpenguin.co.uk>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"jonathanh@nvidia.com" <jonathanh@nvidia.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kthota@nvidia.com" <kthota@nvidia.com>,
	"mmaddireddy@nvidia.com" <mmaddireddy@nvidia.com>,
	"sagar.tv@gmail.com" <sagar.tv@gmail.com>,
	Alan Mikhak <alan.mikhak@sifive.com>
Subject: Re: [PATCH] PCI: dwc: Warn only for non-prefetchable memory resource size >4GB
Date: Wed, 20 May 2020 13:17:17 +0200	[thread overview]
Message-ID: <20200520111717.GB2141681@ulmo> (raw)
In-Reply-To: <DM5PR12MB1276C836FEE46B113112FA92DAB90@DM5PR12MB1276.namprd12.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 6693 bytes --]

On Tue, May 19, 2020 at 10:08:54PM +0000, Gustavo Pimentel wrote:
> On Tue, May 19, 2020 at 15:58:16, Lorenzo Pieralisi 
> <lorenzo.pieralisi@arm.com> wrote:
> 
> > On Tue, May 19, 2020 at 07:25:02PM +0530, Vidya Sagar wrote:
> > > 
> > > 
> > > On 18-May-20 9:24 PM, Lorenzo Pieralisi wrote:
> > > > External email: Use caution opening links or attachments
> > > > 
> > > > 
> > > > On Wed, May 13, 2020 at 05:35:08PM -0500, Bjorn Helgaas wrote:
> > > > > [+cc Alan; please cc authors of relevant commits,
> > > > > updated Andrew's email address]
> > > > > 
> > > > > On Thu, May 14, 2020 at 12:38:55AM +0530, Vidya Sagar wrote:
> > > > > > commit 9e73fa02aa009 ("PCI: dwc: Warn if MEM resource size exceeds max for
> > > > > > 32-bits") enables warning for MEM resources of size >4GB but prefetchable
> > > > > >   memory resources also come under this category where sizes can go beyond
> > > > > > 4GB. Avoid logging a warning for prefetchable memory resources.
> > > > > > 
> > > > > > Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> > > > > > ---
> > > > > >   drivers/pci/controller/dwc/pcie-designware-host.c | 3 ++-
> > > > > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > > index 42fbfe2a1b8f..a29396529ea4 100644
> > > > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > > @@ -366,7 +366,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > > > > >                      pp->mem = win->res;
> > > > > >                      pp->mem->name = "MEM";
> > > > > >                      mem_size = resource_size(pp->mem);
> > > > > > -                   if (upper_32_bits(mem_size))
> > > > > > +                   if (upper_32_bits(mem_size) &&
> > > > > > +                       !(win->res->flags & IORESOURCE_PREFETCH))
> > > > > >                              dev_warn(dev, "MEM resource size exceeds max for 32 bits\n");
> > > > > >                      pp->mem_size = mem_size;
> > > > > >                      pp->mem_bus_addr = pp->mem->start - win->offset;
> > > > 
> > > > That warning was added for a reason - why should not we log legitimate
> > > > warnings ? AFAIU having resources larger than 4GB can lead to undefined
> > > > behaviour given the current ATU programming API.
> > > Yeah. I'm all for a warning if the size is larger than 4GB in case of
> > > non-prefetchable window as one of the ATU outbound translation
> > > channels is being used,
> > 
> > Is it true for all DWC host controllers ? Or there may be another
> > exception whereby we would be forced to disable this warning altogether
> > ?
> > 
> > > but, we are not employing any ATU outbound translation channel for
> > 
> > What does this mean ? "we are not employing any ATU outbound...", is
> > this the tegra driver ? And what guarantees that this warning is not
> > legitimate on DWC host controllers that do use the ATU outbound
> > translation for prefetchable windows ?
> > 
> > Can DWC maintainers chime in and clarify please ?
> 
> Before this code section, there is the following function call 
> pci_parse_request_of_pci_ranges(), which performs a simple validation for 
> the IORESOURCE_MEM resource type.
> This validation checks if the resource is marked as prefetchable, if so, 
> an error message "non-prefetchable memory resource required" is given and 
> a return code with the -EINVAL value.

That's not what the code is doing. pci_parse_request_of_pci_range() will
traverse over the whole list of resources that it can find for the given
host controller and checks whether one of the resources defines prefetch
memory (note the res_valid |= ...). The error will only be returned if
no prefetchable memory region was found.

dw_pcie_host_init() will then again traverse the list of resources and
it will typically encounter two resource of type IORESOURCE_MEM, one for
non-prefetchable memory and another for prefetchable memory.

Vidya's patch is to differentiate between these two resources and allow
prefetchable memory regions to exceed sizes of 4 GiB.

That said, I wonder if there isn't a bigger problem at hand here. From
looking at the code it doesn't seem like the DWC driver makes any
distinction between prefetchable and non-prefetchable memory. Or at
least it doesn't allow both to be stored in struct pcie_port.

Am I missing something? Or can anyone explain how we're programming the
apertures for prefetchable vs. non-prefetchable memory? Perhaps this is
what Vidya was referring to when he said: "we are not using an outbound
ATU translation channel for prefetchable memory".

It looks to me like we're also getting partially lucky, or perhaps that
is by design, in that Tegra194 defines PCI regions in the following
order: I/O, prefetchable memory, non-prefetchable memory. That means
that the DWC core code will overwrite prefetchable memory data with that
of non-prefetchable memory and hence the non-prefetchable region ends up
stored in struct pcie_port and is then used to program the ATU outbound
channel.

> In other words, to reach the code that Vidya is changing, it can be only 
> if the resource is a non-prefetchable, any prefetchable resource will be 
> blocked by the previous call, if I'm not mistaken.
> 
> Having this in mind, Vidya's change will not make the expected result 
> aimed by him.

Given the above I think it does. We've also seen this patch eliminate a
warning that we were seeing before, so I think it has the intended
effect.

> I don't see any problem by having resources larger than 4GB, from what 
> I'm seeing in the databook there isn't any restricting related to that as 
> long they don't consume the maximum space that is addressable by the 
> system (depending on if they are 32-bit or 64-bit system address).
> 
> To be honest, I'm not seeing a system that could have this resource 
> larger than 4GB, but it might exist some exception that I don't know of, 
> that's why I accepted Alan's patch to warn the user that the resource 
> exceeds the maximum for the 32 bits so that he can be aware that he 
> *might* be consuming the maximum space addressable.

I think it's pretty common to have this type of prefetchable memory
region when you connect discrete GPUs to PCIe. It's not unusual for
high-end GPUs to have 8 GiB or even more dedicated video memory and
those will typically be mapped to a prefetchable memory region on
the PCI device.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-05-20 11:17 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
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 [this message]
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=20200520111717.GB2141681@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=Gustavo.Pimentel@synopsys.com \
    --cc=alan.mikhak@sifive.com \
    --cc=amurray@thegoodpenguin.co.uk \
    --cc=bhelgaas@google.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=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 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).