Re: [XenPPC] Xencomm virutal Adress translation question?
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().
>
> _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());
> 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().
Yup, using __va() and __pa() should work because desc is always obtained
via kmalloc(). The free code would need to look like this:
xencomm_free(xc) {
if is_inline(xc)
return
free_page(__va(xc))
}
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Xencomm virutal Adress translation question?
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(). > > _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)); Well this is what is at issue. Acutally this was the first thing I thought of except with xencomm_pa if you are not not physically contiguous we will get back a physical address that cannot (I believe) corretly resolved by __va(). Hinting part of the problem. It's fine if it's Inline but it's the case that it's not inline that there seems there would be a problem. > > 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(). Ok.. this would explain a lot then. If this is the case then forget what I just said above. I need to change my function to not return a xencomm_pa(). Then everything should be fine. > > > -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
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@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
Re: [XenPPC] Xencomm virutal Adress translation question?
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
