linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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¥

  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).