On Thu, Nov 03, 2016 at 06:34:45PM +0100, Paolo Bonzini wrote: > You're right, it needs alignment too. So yeah, early_memalign's code > can be repurposed as the early allocator's morecore callback. For the > current trivial malloc implementation, malloc would be implemented as > ops->morecore(size, align_min). I think we agree on the overall idea > and on having only one function pointer. Yup, already done. But 2, not 1, pointers. Still need 'free' too. > > >> Now morecore talks to both page and virt. page (alloc_page) is > >> initialized with whatever memory wasn't allocated by phys, and takes up > >> its job. virt (alloc_vpages) allocates virtual address space. morecore > >> is now taking not necessarily consecutive physical memory at page > >> granularity, assigning consecutive virtual address to it, and if needed > >> slicing pages into smaller allocations. > > > > vmalloc does all that except the slicing up feature, which is left for > > a rainy day... So I think the implementation I have here for vmemalign > > is still valid for x86's "morecore". > > Fair enough, the slicing can come later. Can you do v3 that (on top of > what you have in this series): > > 1) changes alloc_ops to only have the .memalign callback, with fixed > implementations of malloc/memalign/free functions; done > > 2) makes vmalloc&vmap use alloc_vpages (i.e. use the "virt" allocator); OK > > 3) make alloc_vpages go bottom to top (not strictly necessary but nice); OK, from what base though? 0x8, i.e. just skip NULL? > > 4) replaces vmalloc/vfree with memalign(align=4096)/free in x86/; I thought about this already, but I wasn't sure we wanted to abandon the explicit "I want virt mem" vmalloc naming. memalign/malloc will be vmalloc for any unit test that does setup_vm, but otherwise (if x86 adopted phys_alloc) it wouldn't. Maybe x86 should just never adopt phys_alloc, leading to asserts when setup_vm hasn't been called? > > 5) moves the virt allocator and the vmalloc ops to a new file > lib/vmalloc.c (with install_page() remaining as the sole hook into > arch-specific code), removing what's now dead from lib/vmalloc.c. Yeah, this is a good next step. Will do. Thanks, drew -- 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
