On Thu, 2020-09-03 at 12:08 +0100, Lorenzo Pieralisi wrote: > "Additional Guidance on the Prefetchable Bit in Memory Space BARs" > > I read it 100 times and I still have no idea how it can be > implemented, > it sorts of acknowledges that read side-effects memory can be marked > as a prefetchable BAR *if* the system meets some criteria. > > As if endpoint designers knew the system where their endpoint is > plugged into (+ bit (3) in a BAR is read-only). > > I think that that implementation note must be removed from the > specifications - if anyone dares to follow it this whole > WC resource mapping can trigger trouble. Ah that one ! Yes you are right its completely broken. This part of the spec aims at working around the fact that bridges only have 64-bit prefetchable windows, so anything non-pref has to go below a 32-bit bridge window (effectively making most 64-bit non-pref BARs a pointless waste of silicon). The right fix of course would have been to create a new type of bridge window. But PCI... If you're going to mess around with the SIG, I would suggest that a better approach short of the above would be to allow system software to put 64-bit non-pref BARs below bridge pref windows on PCIe (provided the various otehr restrictions in that note are honored such as bridges not prefetching) and leave it at that. (Unless they already do somewhere else, I forgot ...). This should be sufficient to address the space concern without killing the meaning of the prefetchable bit. As for enabling the _wc files in sysfs, well, you need some serious priviledge to be able to access them, so I don't see a big issue allowing them to exist when "prefetchable" is set regardless of that rule. The Mellanox case might be different. Cheers, Ben.
