From: David Miller <davem@davemloft.net>
To: yinghai@kernel.org
Cc: david.ahern@oracle.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: d63e2e1f3df breaks sparc/T5-8
Date: Tue, 31 Mar 2015 14:19:11 -0400 (EDT) [thread overview]
Message-ID: <20150331.141911.1147249607585406404.davem@davemloft.net> (raw)
In-Reply-To: <CAE9FiQUbKu-UWRBMJwn-fTH+LnEpODnOW+kGHg1FCtTZ3oDepQ@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=utf-8, Size: 2129 bytes --]
From: Yinghai Lu <yinghai@kernel.org>
Date: Tue, 31 Mar 2015 11:16:11 -0700
> On Tue, Mar 31, 2015 at 8:06 AM, David Miller <davem@davemloft.net> wrote:
>> Your patch only allows the condition behind resources that have 64-bits
>> of significance, but that is not what the document above says about
>> when this situation is allowed.
>>
>> Please implement the check either exactly as stated in the errata
>> document, or more loosely if that is not possible, rather than more
>> strictly than allowed.
>>
>> Your overly strict and restrictive checks are what got us into this
>> predicament in the first place. :-(
>
> From that errata:
> ---
> Here are criteria that are sufficient to guarantee correctness for a
> given candidate BAR:
> Â
> The entire path from the host to the adapter is over PCI Express.
> Â
> No conventional PCI or PCI-X devices do peer-t o-peer reads to the
> range mapped by the BAR.
> Â
> The PCI Express Host Bridge does no byte merging. (This is believed to
> be true on most
> platforms.)
> Â
> Any locations with read side-effects are never the target of Memory
> Reads with the TH bit Set.
> See Section 2.2.5
> ---
>
> We can verify first one that we have all pcie device all the way to
> the hostbridge.
>
> But we can not verify or guarantee other three.
Lack of peer-to-peer reads we can assume, the byte merging we can
add as a per-controller attribute in the future if it turns out there
are some that do and it matters (I doubt this will ever be necessary)
and the side-effect issue is outside the scope of the PCI layer.
> System should get better about the constraints with system design.
> So if it would assign 64bit (and above 4G) mmio to those non-pref 64bit BAR,
> that means it already make sure system design will follow those criteria.
> and then we can safely set pref bit in resource flags.
I totally disagree, I think your test is too stringent and should be
significantly relaxed if not removed entirely.
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2015-03-31 18:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 16:51 d63e2e1f3df breaks sparc/T5-8 David Ahern
2015-03-26 20:43 ` Yinghai Lu
2015-03-26 23:27 ` David Ahern
2015-03-27 21:01 ` Yinghai Lu
2015-03-27 21:50 ` David Miller
2015-03-27 22:51 ` Yinghai Lu
[not found] ` <CABhMZUVqgsYdT4wn2H8hsrh4f=6hT0G+sg=wwYSt33+jtvBS9A@mail.gmail.com>
2015-03-29 18:32 ` David Miller
2015-04-03 15:45 ` Bjorn Helgaas
2015-04-03 16:48 ` David Miller
2015-03-27 23:57 ` Yinghai Lu
2015-03-28 0:32 ` David Ahern
2015-03-28 0:36 ` David Ahern
2015-03-28 3:19 ` Yinghai Lu
2015-03-28 3:22 ` David Ahern
2015-03-28 3:27 ` Yinghai Lu
2015-03-28 3:45 ` David Ahern
2015-03-28 5:26 ` Yinghai Lu
2015-03-28 14:48 ` David Ahern
2015-03-28 20:24 ` Yinghai Lu
2015-03-29 14:47 ` David Ahern
2015-03-29 20:07 ` Yinghai Lu
2015-03-30 22:54 ` David Ahern
2015-03-31 1:06 ` Yinghai Lu
2015-03-31 4:10 ` David Ahern
2015-03-31 16:53 ` Yinghai Lu
2015-03-31 17:04 ` David Ahern
2015-03-31 20:28 ` Yinghai Lu
2015-03-31 22:29 ` David Ahern
2015-03-31 22:38 ` Yinghai Lu
2015-03-31 22:42 ` David Ahern
2015-03-31 15:06 ` David Miller
2015-03-31 18:16 ` Yinghai Lu
2015-03-31 18:19 ` David Miller [this message]
2015-03-31 18:25 ` Yinghai Lu
2015-03-28 1:05 ` Sam Ravnborg
2015-03-28 2:07 ` Yinghai Lu
2015-03-28 8:18 ` Sam Ravnborg
2015-03-28 18:16 ` David Miller
2015-03-28 20:19 ` Yinghai Lu
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=20150331.141911.1147249607585406404.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=bhelgaas@google.com \
--cc=david.ahern@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=yinghai@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).