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.
