| Message ID | 1477939906-28802-5-git-send-email-drjones@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 31/10/2016 19:51, 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, but > let's give it the option. arm and powerpc use the early_alloc_ops, > built on phys_alloc, but x86 already has virtual memory management, > so we can build on that instead. What are your plans for using them? vmalloc imposes a pretty large alignment and is quite different from early_alloc_ops, so I'm not sure it's a good idea to conflate the two into the same high-level API. Thanks, Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 01, 2016 at 03:48:54PM +0100, Paolo Bonzini wrote: > > > On 31/10/2016 19:51, 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, but > > let's give it the option. arm and powerpc use the early_alloc_ops, > > built on phys_alloc, but x86 already has virtual memory management, > > so we can build on that instead. > > What are your plans for using them? vmalloc imposes a pretty large > alignment and is quite different from early_alloc_ops, so I'm not sure > it's a good idea to conflate the two into the same high-level API. I was mostly thinking that common lib/* code might want to start using malloc, etc. Unless x86 implements them then that won't be possible. I don't have a need yet though, so I'm fine with leaving it until a different allocation scheme could be used as the base. Although, that said, we could use the vmalloc allocation scheme now, just to satisfy malloc, etc., and then improve the underlying scheme later too. Anyway, I see I had a bug in my memalign implementation, so it needs a bit more work either way. Thanks, drew -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/lib/x86/vm.c b/lib/x86/vm.c index 0882e0a478ca..1e1b74bfb645 100644 --- a/lib/x86/vm.c +++ b/lib/x86/vm.c @@ -118,15 +118,39 @@ static void setup_mmu(unsigned long len) printf("cr4 = %lx\n", read_cr4()); } +static void *vcalloc(size_t nmemb, size_t size) +{ + return vmalloc(nmemb * size); +} + +static void *vmemalign(size_t alignment, size_t size) +{ + size_t size_aligned; + void *addr; + + assert(alignment && !(alignment & (alignment - 1))); + size_aligned = ALIGN(size, alignment); + addr = vmalloc(size_aligned); + return addr + (size_aligned - size); +} + +static struct alloc_ops vm_alloc_ops = { + .malloc = vmalloc, + .calloc = vcalloc, + .free = vfree, + .memalign = vmemalign, +}; + void setup_vm() { assert(!end_of_memory); end_of_memory = fwcfg_get_u64(FW_CFG_RAM_SIZE); heap_init(&edata, end_of_memory - (unsigned long)&edata); setup_mmu(end_of_memory); + alloc_ops = &vm_alloc_ops; } -void *vmalloc(unsigned long size) +void *vmalloc(size_t size) { void *mem, *p; unsigned pages; diff --git a/lib/x86/vm.h b/lib/x86/vm.h index 6a4384f5a48d..3c9a71d03cf9 100644 --- a/lib/x86/vm.h +++ b/lib/x86/vm.h @@ -7,7 +7,7 @@ void setup_vm(); -void *vmalloc(unsigned long size); +void *vmalloc(size_t size); void vfree(void *mem); void *vmap(unsigned long long phys, unsigned long size); void *alloc_vpage(void);
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, but let's give it the option. arm and powerpc use the early_alloc_ops, built on phys_alloc, but x86 already has virtual memory management, so we can build on that instead. Signed-off-by: Andrew Jones <drjones@redhat.com> --- lib/x86/vm.c | 26 +++++++++++++++++++++++++- lib/x86/vm.h | 2 +- 2 files changed, 26 insertions(+), 2 deletions(-)