Re: [nicholas.johnson-opensource@outlook.com.au: [PATCH v6 3/4] PCI: Fix bug resulting in double hpmemsize being assigned to MMIO window]

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2019-06-20 at 08:43 -0500, Bjorn Helgaas wrote:
> This is as it should be.  Non-prefetchable windows are 32 bits, and
> in general non-prefetchable BARs must be placed there.
> 
> There is some wiggle room in pure PCIe systems because PCIe reads
> always contain an explicit length, so in some cases it is safe to
> put a non-prefetchable BAR in a prefetchable window (see the
> implementation note in sec 7.5.1.2.1).  But I don't think Linux
> currently implements this.

We don't, we probably should, but seeing our current allocation code, I
dread of the end result ...

We would need a host bridge flag to indicate it's safe (no byte merging
at the PHB). I know most host bridge implementations don't
differenciate prefetchable from non-prefetchable outbound windows so
should be fine, and the other side effects are generally attributes of
the mapping done in the MMU and thus depend on the device BAR
attribute, not the bridge windows in the way.

I'm not 100% sure how/if x86 throws a wrench into this with MTRRs
(could a BIOS setup one of these things to cover a bridge/switch
prefetchable window ? That would be a bad idea but bad ideas is what
BIOS vendors often come up with).

Cheers,
Ben.