On 03/11/2016 19:42, Andrew Jones wrote:
> On Thu, Nov 03, 2016 at 07:20:20PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 03/11/2016 19:12, Andrew Jones wrote:
>>> 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.
>>
>> Didn't we say that the morecore allocator would only grow?
>
> morecore[phys_alloc] only grows, free -> {}
> morecore[vmemalign] can do both, free -> vfree
Though there'd be no caller of .free, and vfree is sitting mostly unused
right now. You decide.
> Hmm, I see what's going on now in x86. First, setup_vm should be doing
> setup_mmu *before* 'free_memory' (what I renamed to heap_init), because
> it assumes it's using virtual address with page_alloc/free. Second, x86
> creates an identity map up to end_of_memory, and that's the last address
> the heap knows about too. So, if we want to allocate free virtual
> addresses upwards, then we should start from end_of_memory.
Right, from 2G. There's even a comment. :)
>>>> 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.
>
> This one looks like we'll need to cleanup the install_page parameter
> expectations a bit in order to keep arch-specific stuff out of the callers,
> but that should be doable.
The first argument can go---its always phys_to_virt(read_cr3())---and
with that it should be fine.
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
