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?

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().


-JX

On Jan 27, 2007, at 8:13 PM, Jerone Young wrote:

I'm facing an interesting problem and I was wondering if anyone on the
list (Jimi) could answer it.

So in the xencomm patch that has been floating the list I have functions
xencomm_map & xencomm_map_early . Now currently they return physcial
addresses regardless of the case. BUT, in the cases where they are not
inline I face a BIG problem. As I have no way to truly translate back to
a virtual address to free the memory with xencomm_free (__va() isn't
going to cut it). So I currently have a patch (yet to go to the list)
that has xencomm_map & early returning a phyiscal address if it's inline
and a virtual address if it is not.

Well then I have a hack in xencomm_vtop that says if the address has bit XENCOMM_INLINE_FLAG. Then just return the address, since you are already
physical. So when xencomm_pa() is used within the code it will return
the proper address.

Is this acceptable? I'm not sure of any other way of going about this
since there is no good way to translate back to a virtual address to use
xencomm_free.


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


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

Reply via email to