Xen devel - Sep 2005 - problem with direct_remap_pfn_range parameters

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 15 Sep 2005, at 17:45, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> 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 :-)
I think direct_remap_pfn_range() is not accessed directly from common 
code, so the interface can easily be changed. If so, changing to take a 
vma instead of mm is the obvious fix.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

sparse/drivers/xen is slowly (but surely) becoming common code
and direct_remap_pfn_range is called in
drivers/xen/privcmd/privcmd.c.  Changing that usage
means changing many other (x86) files, including some that
call it with &init_mm.  (Is there a parent vma for
init_mm?)

Or did I misunderstand your point?

Thanks,
Dan
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
> Sent: Thursday, September 15, 2005 11:17 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] problem with direct_remap_pfn_range 
> parameters
> 
> 
> On 15 Sep 2005, at 17:45, Magenheimer, Dan (HP Labs Fort 
> Collins) wrote:
> 
> > 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 :-)
> 
> I think direct_remap_pfn_range() is not accessed directly from common 
> code, so the interface can easily be changed. If so, changing 
> to take a 
> vma instead of mm is the obvious fix.
> 
>   -- Keir
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 15 Sep 2005, at 19:08, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> sparse/drivers/xen is slowly (but surely) becoming common code
> and direct_remap_pfn_range is called in
> drivers/xen/privcmd/privcmd.c.  Changing that usage
> means changing many other (x86) files, including some that
> call it with &init_mm.  (Is there a parent vma for
> init_mm?)
>
> Or did I misunderstand your point?
My point was garbled. No code outside our sparse tree directly calls 
direct_remap_pfn_range() so we have free reign to define its interface.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel