On 02/11/2016 21:52, Andrew Jones wrote:
> We've had malloc, calloc, free, and memalign available for quite a
> while, and arm and powerpc make use of them. x86 hasn't yet, which
> is fine, but could lead to problems if common lib code wants to make
> use of them. While arm and powerpc currently use early_alloc_ops,
> built on phys_alloc, x86 does not initialize phys_alloc and has its
> own memory management, vmalloc. This patch enables vmalloc to be
> used as the underlying allocator, but there are two drawbacks:
>
> 1) Every allocation will allocate at least one page.
> 2) It can only be used with the MMU enabled.
>
> Drawback (1) is probably fine for kvm-unit-tests. Drawback (2) may
> not be, as common lib code may get invoked at any time by any unit
> test, including ones that don't have the MMU enabled. However, as
> we only switch alloc_ops to the vmalloc based implementations in
> setup_vm, where the MMU is enabled, then they'll be safe to use for
> any unit test that invokes setup_vm first. If the unit test does
> not invoke setup_vm first then alloc_ops will use the default
> implementations, the ones based on phys_alloc, and will result
> in asserts firing if phys_alloc_init has not be called first.
>
> While this patch may not enable anything right now, I think it
> makes sense to enable these alloc ops before they're needed, because
> then everything will most likely just work when a future common lib
> function that uses malloc is introduced. If that common function
> results in a unit test hitting an assert, then the test writer will
> just need to decide if they want to use phys_alloc or vmalloc and
> call the appropriate init function first.
So it seems to me that phys_alloc should be implemented _on top_ of
virtual memory. Basically, the alloc_ops should not be
malloc/calloc/free/memalign. The current
early_malloc/early_calloc/early_free/early_memalign should just be
renamed to malloc/calloc/free/memalign.
Instead, you only need an op which is
void *morecore(unsigned long size);
The default implementation is basically "base += size; return base -
size;". When you turn on virtual memory (hopefully, that's before any
allocation!) map_core is changed to point to a function that calls
install_page to fetch memory if needed.
Assuming lib/x86/vm.c is changed to allocate upwards (not downwards),
something like this would do:
addr = malloc_free;
available = malloc_top - addr;
if (available < size) {
if (vfree_bottom == malloc_top + 1) {
// can reuse top of previous segment
vsize = PAGE_ALIGN(size - available);
vaddr = alloc_vpages(vsize >> PAGE_SHIFT);
assert(vaddr == malloc_top + 1);
} else {
// ignore free space at end of previous segment
vsize = PAGE_ALIGN(size);
addr = vaddr =
alloc_vpages(vsize >> PAGE_SHIFT);
}
malloc_top = vaddr + vsize - 1;
}
malloc_free = addr + size;
return addr;
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
