Messages in this thread | | | From | (Eric W. Biederman) | Date | Wed, 30 Apr 2008 13:35:47 -0700 | Subject | Re: [patch] x86, voyager: fix ioremap_nocache() |
| |
"H. Peter Anvin" <hpa@zytor.com> writes:
> 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
| |