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_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());
> 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:
IBM Linux Technology Center
Xen-ppc-devel mailing list