"H. Peter Anvin" <hpa@zytor.com> writes:

quoted text
> David Miller wrote:
>> I think this is a reasonable course of action.
>>
>> That leaves one of Jeff's concerns, what to do with pci_iomap().  That
>> was designed to give mappings with caching enabled, and as a result we
>> probably should make it behave that way.
>
> Yes, it should.  Just be clear that *that* is a semantic change over what the
> code currently does; it would appear that that is what the code is *trying* to
> do.
>
> I believe on x86 it will still get clamped by the MTRRs, at least initially (I
> don't think we have flipped the default MTRR type to WB yet) but that would
> immediately change the behaviour on non-x86 architectures.

Flipping the default MTRR type to WB has the potential to break an SMM
monitor which does I/O and isn't using our page tables.  So we need to
be very careful about that direction.  Finally I remember what
the specific and really scary failure mode with SMM and mucking with
the MTRRs is.

There don't appear to be many bars that set IORESOURCE_CACHABLE for use
with pci_iomap so it doesn't appear to be much of an issue.

In addition it looks like we should map IORESOURCE_PREFETCH to ioremap_wc
in pci_iomap, for those places that can take advantage of it.  It
might not always work (hardware is like that) but semantically pci
prefetch is the same as the WC attribute (reads and writes have no
side effects).  I believe on x86 if we want to get cacheline sized
reads (read prefetch) there is special instruction in the latest
processors we need to use on a wc area.

Eric
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/