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

Re: [Xen-devel] [PATCH 2/9] Linux kernel infrastructure for Xen Share ac

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2/9] Linux kernel infrastructure for Xen Share access
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Wed, 14 Jun 2006 13:26:20 -0400
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Jun 2006 10:26:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1149573502.5183.46.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
References: <1149572143.5183.25.camel@xxxxxxxxxxxxxxxxxxxxx> <1149573502.5183.46.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
Rusty Russell wrote:

The entire hypercall interface is arch-wrapped, which is probably
overkill, but I wasn't entirely sure of the needs of non-x86
architectures.  Some of this should almost certainly be in common code.

diff -r 6d476981e3a5 -r 07a00d96357d 
linux-2.6-xen-sparse/include/asm-i386/mach-xen/asm/share.h


+struct xen_share *create_share(share_ref_t share_ref, unsigned pages)

<snip>

+
+       prot = __pgprot(_PAGE_PRESENT|_PAGE_RW|_PAGE_DIRTY|_PAGE_ACCESSED);
+       err = direct_kernel_remap_pfn_range((unsigned long)vma->addr,
+                                           share_ref, pages * PAGE_SIZE,
+                                           prot, DOMID_SELF);

Using share_ref as the 2nd parameter to remap_pfn_range it becomes clear that share_ref is really a page frame number. This is also made clear in xen/arch/x86/share.c.

My question is: is it useful to abstract the share reference when it is always going to be a page number? Is there any architecture where it wouldn't be feasible to refer to a share by page number?

Really this is just a readability issue.

Mike


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

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