Actually that hack did not workout. But do need a better way to do this.
As anyone the code will work great in some places as long as it is
allways is inline. Perhaps xencomm_map & xencomm_early may not be the
best approaches after all.

On Sat, 2007-01-27 at 19:13 -0600, 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