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
