Re: [Xen-devel] [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Thu, Mar 31, 2016 at 12:46:24AM -0600, Jan Beulich wrote:
> >>> On 30.03.16 at 18:44, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote:
> >> >>> On 24.03.16 at 21:00, <konrad.wilk@xxxxxxxxxx> wrote:
> >> > @@ -266,16 +275,15 @@ void *vzalloc(size_t size)
> >> >      return p;
> >> >  }
> >> >  
> >> > -void vfree(void *va)
> >> > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
> >> 
> >> Just to repeat: This "caller provides size" worries me, the more that
> >> this doesn't mirror anything the allocation side does. Would you mind
> >> providing a case where using vm_size() instead is not correct?
> > 
> > When the virtual addresses (to which we will stitch the pages allocated
> > by vmalloc) are not allocated (provided?) by vmap.
> > 
> > vm_size() will be very unhappy if that virtual address it is provided with
> > are not from the 'vmap' pool and will return 0.
> 
> Hmm, okay, I now see that I got mislead by "This allows users (such
> as xSplice) to provide their own mechanism to set the page flags",
> which suggested to me that all you want is control over those flags.

Sorry about that! That was the initial part which didn't work out
as the displacement from kernel virtual address ranges to vmap ones
was 34-bits. And that broke ELF relocations which were 32-bit!


> Now that I look again I realize that I could have easily spotted the
> actual intention right away. If all you really want to re-use from the
> existing vmalloc() is the allocation mechanism of the set of pages,
> then no, I don't think this should be done by playing with vmalloc().
> Just have your caller do that allocation itself.

Like it was in v4 :-)

I will drop this and rework the patch that does the backing memory operation
to use its own version.
> 
> If, otoh, you left that VA management to (an extended version of)
> vmap(), by e.g. allowing the caller to request allocation from a
> different VA range (much like iirc x86-64 Linux handles its modules
> address range allocation), things would be different. After all the
> VA management is the important part here, while the backing
> memory allocation is just a trivial auxiliary operation.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel