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-ppc-devel

Re: [XenPPC] Xencomm virutal Adress translation question?

To: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>
Subject: Re: [XenPPC] Xencomm virutal Adress translation question?
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Mon, 29 Jan 2007 11:55:15 -0600
Cc: xen-ppc-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 29 Jan 2007 09:55:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <10D138A7-C1C9-461C-A186-C55B37ED1753@xxxxxxxxxxxxxx>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <1169946819.3904.8.camel@thinkpad> <10D138A7-C1C9-461C-A186-C55B37ED1753@xxxxxxxxxxxxxx>
Reply-to: Hollis Blanchard <hollisb@xxxxxxxxxx>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sun, 2007-01-28 at 10:40 -0500, Jimi Xenidis wrote:
> Ok, xencomm is simply a data structure that describes (we'll call it  
> the descriptor or "desc") the physical memory that another data  
> structure occupies (we'll call "data").
> 
> Sometimes this "data" is self described, such that all the data  
> exists on a single page, or proven to be physically contiguous, so it  
> is tagged as "inline" and no separate descriptor is necessary and  
> therefore no allocation (or free) is required, so lets only consider  
> when allocation is required.
> 
> There are two methods to create this desc: (1) _map_early() and (2)  
> _map().
> 
> _map_early() is used when allocation occurs from the stack and the  
> size of data is known to be a small number (less than 4) pages, this  
> is helpfull for performance and in cases where the allocator is  
> unavailable (too early or in interrupt).  The descriptor returned  
> from this call does not require a corresponding free().
> BTW: the above paragraph makes me want to rename _map_early() to  
> _map_auto() or _map_stack() which in an obvious manner explains why  
> no free() is needed. Hollis?

I already suggested calling it _noalloc().

> Now to answer your question:
> 
> In the case of _map(), if the data cannot be "inlined" then a single  
> kernel page is allocated to describe up to 511 (+-1) pages of data,  
> this page is known to easily be translated from kernel_virtual to  
> kernel_physycal using __va() and __pa() function, so there should be  
> no problem in using:
>     desc = __pa(alloc_page());
> and:
>     free_page(__va(desc));
> 
> BTW: xencomm_pa(), should only be used when building the contents of  
> "desc" in order to describe "data", _not_ in creating the value of  
> "desc", that should always be __pa().

Yup, using __va() and __pa() should work because desc is always obtained
via kmalloc(). The free code would need to look like this:

xencomm_free(xc) {
        if is_inline(xc)
                return
        free_page(__va(xc))
}

-- 
Hollis Blanchard
IBM Linux Technology Center


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

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