qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 1/9] Export function for VA defined ram allocation
Date: Wed, 21 Oct 2009 13:48:48 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]