From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <helgaas@kernel.org>,
catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
Clint Sbisa <csbisa@amazon.com>
Subject: Re: [PATCH] arm64: Enable PCI write-combine resources under sysfs
Date: Fri, 04 Sep 2020 08:26:23 +1000 [thread overview]
Message-ID: <56d2f113acef3055d3bf771fa6cd7c976fc6da65.camel@kernel.crashing.org> (raw)
In-Reply-To: <20200903110844.GB11284@e121166-lin.cambridge.arm.com>
On Thu, 2020-09-03 at 12:08 +0100, Lorenzo Pieralisi wrote:
> "Additional Guidance on the Prefetchable Bit in Memory Space BARs"
>
> I read it 100 times and I still have no idea how it can be
> implemented,
> it sorts of acknowledges that read side-effects memory can be marked
> as a prefetchable BAR *if* the system meets some criteria.
>
> As if endpoint designers knew the system where their endpoint is
> plugged into (+ bit (3) in a BAR is read-only).
>
> I think that that implementation note must be removed from the
> specifications - if anyone dares to follow it this whole
> WC resource mapping can trigger trouble.
Ah that one ! Yes you are right its completely broken.
This part of the spec aims at working around the fact that bridges only
have 64-bit prefetchable windows, so anything non-pref has to go below
a 32-bit bridge window (effectively making most 64-bit non-pref BARs a
pointless waste of silicon).
The right fix of course would have been to create a new type of bridge
window. But PCI...
If you're going to mess around with the SIG, I would suggest that a
better approach short of the above would be to allow system software to
put 64-bit non-pref BARs below bridge pref windows on PCIe (provided
the various otehr restrictions in that note are honored such as bridges
not prefetching) and leave it at that. (Unless they already do
somewhere else, I forgot ...).
This should be sufficient to address the space concern without killing
the meaning of the prefetchable bit.
As for enabling the _wc files in sysfs, well, you need some serious
priviledge to be able to access them, so I don't see a big issue
allowing them to exist when "prefetchable" is set regardless of that
rule. The Mellanox case might be different.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-03 22:27 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200831151827.pumm2p54fyj7fz5s@amazon.com>
[not found] ` <20200902113207.GA27676@e121166-lin.cambridge.arm.com>
[not found] ` <20200902142922.xc4x6m33unkzewuh@amazon.com>
2020-09-02 16:47 ` [PATCH] arm64: Enable PCI write-combine resources under sysfs Lorenzo Pieralisi
2020-09-02 17:21 ` Catalin Marinas
2020-09-02 17:54 ` Lorenzo Pieralisi
2020-09-02 23:03 ` Benjamin Herrenschmidt
2020-09-02 23:08 ` Benjamin Herrenschmidt
2020-09-02 23:08 ` Benjamin Herrenschmidt
2020-09-02 23:07 ` Benjamin Herrenschmidt
2020-09-03 11:08 ` Lorenzo Pieralisi
2020-09-03 14:36 ` Clint Sbisa
2020-09-03 22:26 ` Benjamin Herrenschmidt [this message]
2020-09-07 23:33 ` Benjamin Herrenschmidt
2020-09-10 9:46 ` Lorenzo Pieralisi
2020-09-10 10:54 ` Leon Romanovsky
2020-09-10 12:37 ` Jason Gunthorpe
2020-09-10 15:17 ` Lorenzo Pieralisi
2020-09-10 17:10 ` Jason Gunthorpe
2020-09-10 21:46 ` Benjamin Herrenschmidt
2020-09-10 23:29 ` Jason Gunthorpe
2020-09-11 0:39 ` Benjamin Herrenschmidt
2020-09-11 14:21 ` Jason Gunthorpe
2020-09-11 21:42 ` Clint Sbisa
2020-09-14 14:17 ` Jason Gunthorpe
2020-09-14 14:24 ` Clint Sbisa
2020-09-14 14:38 ` Jason Gunthorpe
2020-09-14 21:42 ` Benjamin Herrenschmidt
2020-09-14 22:00 ` Benjamin Herrenschmidt
2020-09-14 22:32 ` Clint Sbisa
2020-09-14 22:57 ` Jason Gunthorpe
2020-09-14 23:25 ` Benjamin Herrenschmidt
2020-09-15 10:18 ` Lorenzo Pieralisi
2020-09-15 11:05 ` Jason Gunthorpe
2020-09-15 23:17 ` Benjamin Herrenschmidt
2020-09-15 23:40 ` Jason Gunthorpe
2020-09-16 7:59 ` Benjamin Herrenschmidt
2020-09-16 12:12 ` Jason Gunthorpe
2020-09-16 14:09 ` Lorenzo Pieralisi
2020-09-16 14:14 ` Jason Gunthorpe
2020-09-16 23:59 ` Benjamin Herrenschmidt
2020-09-17 10:28 ` Lorenzo Pieralisi
2020-09-17 11:32 ` Jason Gunthorpe
2020-09-17 14:01 ` Lorenzo Pieralisi
2020-09-17 16:08 ` Will Deacon
2020-09-16 12:48 ` Leon Romanovsky
2020-09-16 8:33 ` Will Deacon
2020-09-16 8:48 ` Catalin Marinas
2020-09-16 14:15 ` Lorenzo Pieralisi
2020-09-16 17:00 ` Catalin Marinas
2020-09-16 21:29 ` Benjamin Herrenschmidt
2020-09-16 12:08 ` Jason Gunthorpe
2020-09-15 23:00 ` Benjamin Herrenschmidt
2020-09-15 23:12 ` Clint Sbisa
2020-09-14 21:41 ` Benjamin Herrenschmidt
2020-08-21 15:51 Clint Sbisa
2020-08-27 14:41 ` Clint Sbisa
2020-08-31 15:22 ` Clint Sbisa
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=56d2f113acef3055d3bf771fa6cd7c976fc6da65.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=csbisa@amazon.com \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=will@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).