WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] problem with direct_remap_pfn_range parameters

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] problem with direct_remap_pfn_range parameters
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Thu, 15 Sep 2005 09:45:32 -0700
Delivery-date: Thu, 15 Sep 2005 16:43:49 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcW6FONUU24FirFmSjS4vzdTQeqgEA==
Thread-topic: 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>