In xenlinux, various routines use a function called
direct_remap_pfn_range which is derived from a similar
function in linux called remap_pfn_range. Xen/ia64
can use the original linux function here (because
all guest physical memory is virtualized), but
unfortunately the parameters have diverged: the
xenlinux version passes an mm_struct (vm->vm_mm)
but the original linux passes the "parent" vma_struct.
Also there is an extra parameter in the xenlinux
version.
In particular, I am trying to reduce the need for
arch-specific ifdef's in drivers/xen (we've been
maintaining them out of tree) and privcmd/privcmd.c
calls direct_remap_pfn_range. Xen/ia64 could
just put a define in an archdep file such as:
#define direct_remap_pfn_range(a,b,c,d,e,f) \
remap_pfn_range(a,b,c,d,e)
but unfortunately there's not a reliable way
to get back from an mm_struct to the vma_struct.
Would it be possible to change the interface for
direct_remap_pfn_range to pass the vma_struct
and extract the mm_struct in the routine?
(I see this is complicated by the fact that
init_mm is passed as a parameter in some calls.)
Else could the call be abstracted (e.g. as
arch_remap_pfn_range) with the first parameter
a vma_struct? E.g. in x86:
#define arch_remap_pfn_range(a,b,c,d,e,f) \
direct_remap_pfn_range( \
((a)?a->vm_mm:&init_mm),b,c,d,e,f)
Else we could just have an ifdef in privcmd.c
#ifdef _ARCH_HAS_PHYSMEM_VIRTUALIZED //ia64, ppc?
if ( (rc = remap_pfn_range(vm, ...
#else
if ( (rc = direct_remap_pfn_range(vm->vm_mm, ...
#endif
I see there are a number of possible solutions and
none of them are particularly pretty, so thought
I would open a discussion rather than submit an
ugly patch that would likely be rejected :-)
Feedback/ideas (or just change/commit) appreciated!
Thanks,
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home