Messages in this thread | | | Date | Mon, 29 Nov 2004 19:38:26 -0800 | From | William Lee Irwin III <> | Subject | Re: [4/7] Xen VMM patch set : /dev/mem io_remap_page_range for CONFIG_XEN |
| |
On Fri, Nov 19, 2004 at 11:22:51PM +0000, Ian Pratt wrote: >> This patch modifies /dev/mem to call io_remap_page_range rather than >> remap_pfn_range under CONFIG_XEN. This is required because in arch
On Tue, Nov 30, 2004 at 04:08:12AM +0100, Andrea Arcangeli wrote: > Why don't we change /dev/mem to use io_remap_page_range unconditionally > for ranges above high_memory? Clearly io_remap_page_range can map device > space, and I guess that's what io_remap_page_range is there for. sparc > and sparc64 are the only two ones implementing io_remap_page_range, so > maybe Dave or Wli can tell us if there's any penalty in using > io_remap_page_range in mmap(/dev/mmap) for phys ranges above > high_memory. I don't know the sparc architectural details of mk_pte_io > invoked by io_remap_page_range of the sparc arch. > There's also an issue with io_remap_page_range where sparc has 6 args > while everyone else has 5 args. It's perfectly fine that sparc will be > the only one parsing the last value, but we should pass that last value > to all archs, so that people can avoid writing code like the below > (drivers/char/drm):
On sparc32, all IO memory is above the 32-bit boundary. So it's generally okay for that. The general ongoing work in the io_remap_page_range() area to unify the sparc32/sparc64 case with other architectures is based in part on the remap_pfn_range() work (as noted by davem in another followup).
Unfortunately the effort to debug the effects of pending changes in 2.6.10-rc2-mm3 is blocking the io_remap_page_range() work.
-- wli - 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/
| |