lkml.org 
[lkml]   [2004]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.351 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site