| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [XenPPC] Xencomm virutal Adress translation question?
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
| |
|
Home