[Qemu-devel] Re: [PATCH 1/9] Export function for VA defined ram allocation

[Anthony Liguori <anthony@codemonkey.ws>]

Paolo Bonzini wrote:
> What about this:
>
> -ram_addr_t qemu_ram_alloc(ram_addr_t size)
> +ram_addr_t qemu_ram_alloc_at(ram_addr_t size, void *map_at)
>  {
>      RAMBlock *new_block;
>
>      size = TARGET_PAGE_ALIGN(size);
>      new_block = qemu_malloc(sizeof(*new_block));
>
> -    new_block->host = qemu_vmalloc(size);
> +    if (map_at) {
> +        new_block->host = map_at;
> +    } else {
> +        new_block->host = qemu_vmalloc(size);
> +    }
>  #ifdef MADV_MERGEABLE
>      madvise(new_block->host, size, MADV_MERGEABLE);
>  #endif
>
> and calling mmap where you're currently calling _qemu_ram_alloc?

I'm not sure.  It's definitely better but I don't think we really want 
machines to decide whether their memory is allocated generally 
speaking.  That's the advantage of hiding behind qemu_ram_alloc().

Another way to look at this is that it's roughly the same problem as 
qemu-kvm's -mem-path.  -mem-path doesn't really address subregions 
though.  In order to support shared memory regions, I think it necessary 
to be able to say something like, ram region XX..YY should be tied to 
this mmap()'d region.  Either way, these operations should be 
transparent to the caller of qemu_ram_alloc().

I didn't want to suggest solving the larger problem because I didn't 
want to bog down an otherwise reasonable series.

Regards,

Anthony Liguori

> Paolo