Re: d63e2e1f3df breaks sparc/T5-8

[David Miller]

From: Yinghai Lu <yinghai@xxxxxxxxxx>
Date: Tue, 31 Mar 2015 11:16:11 -0700

> On Tue, Mar 31, 2015 at 8:06 AM, David Miller <davem@xxxxxxxxxxxxx> 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.