Re: mapping PCI registers with write combining (and PAT on x86)...

Roland Dreier <rdreier@xxxxxxxxx> writes:

Suppose that I would like to map some PIO registers (in a PCI BAR) to
userspace, and I would like to enable write combining if possible.

I have two problems. First, there's no generic interface for
requesting write combining if possible when doing
io_remap_pfn_range(). Would it make sense to define
pageprot_writecombine for all architectures (and make it fall back to
doing non-cached access if write combining is not possible)? And it
seems that making pgprot_noncached() universal wouldn't hurt either.

So I think we may simplify this but there is pci_mmap_page_range. That
already handles this for the architectures that currently support it.
So it is probably the case the fbdev should be changed to use that.

I am certainly in favor of simpler infrastructure like making
pgprot_writecombine and pgprot_uncached universal but I would like to
start with what works today.

Then we can go reexamine things like the ia64 slavishly trusting the
BIOS to know which page protections are good.

Second, given the extreme shortage of MTRRs, it seems that write
combining is not really possible in general on x86 without some
interface to use PATs instead. What is holding up something like Eric
Biederman's patches from going in?

No one had any serious objections to my patches as they were. The actual
problem was that the patches were incomplete. In particular if you
mismatch page protections it is possible to get silent data corruption
or processor crashes. So we need checks to ensure all mappings of
a given page are using the same protections.

To a certain extent I think adding those checks really is a strawman
and should not stop the merge effort, because we have this feature and
those possible bugs on other architectures right now and we don't have
those checks. But I also think in the long term we need them, it just
requires several days of going through the mm so we don't leave any
path uncovered.

Right now we end up with stuff like the absolutely hair-raising code
in drivers/video/fbmem.c shown below. I really would like to make
progress towards having a better interface for doing this stuff, and
I'm more than willing to work on getting something mergable.

I hope my comments help.

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

Relevant Pages

  • Re: [patch 00/17] multi size, and giant hugetlb page support, 1GB hugetlb for x86
    ... > only with just 1G hugepages, though, we haven't yet taught ... Yes I don't like the proc interface, nor the way it has been extended ... the per-node nr_hugepages). ... >> The other thing I did was try to shuffle the patches around a bit. ...
    (Linux-Kernel)
  • Re: NUMA API
    ... This is against every good design principal. ... The API design should be general enough to work for all the ... be extendable for future architectures. ... This is only the lowest level interface. ...
    (Linux-Kernel)
  • [RFC] Changes to the driver model class code.
    ... start us on the way toward cleaning up the driver model code so that ... of interface for the main class code itself. ... taken his tty and input patches that convert those subsystems over to ... So I'll be slowly converting the kernel over to using this new ...
    (Linux-Kernel)
  • Re: [ANNOUNCE] hotplug-ng 002 release
    ... Or just send those patches earlier:) ... > ended up ignoring the interface bits altogether. ... as this patch ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [ANNOUNCE] hotplug-ng 002 release
    ... > Or just send those patches earlier:) ... >> ended up ignoring the interface bits altogether. ... > a USB device, but by the time these files are created, it should be fine ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)