From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike D. Day" Subject: Re: [PATCH 2/9] Linux kernel infrastructure for Xen Share access Date: Wed, 14 Jun 2006 13:26:20 -0400 Message-ID: <449046BC.60200@us.ibm.com> References: <1149572143.5183.25.camel@localhost.localdomain> <1149573502.5183.46.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1149573502.5183.46.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Rusty Russell Cc: Xen Mailing List List-Id: xen-devel@lists.xenproject.org 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) > + > + 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