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

Reply via email to