Re: [XenPPC] Xencomm virutal Adress translation question?

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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