From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N0gF3-0007UD-F8
	for qemu-devel@nongnu.org; Wed, 21 Oct 2009 14:49:01 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N0gEy-0007Pe-LJ
	for qemu-devel@nongnu.org; Wed, 21 Oct 2009 14:49:00 -0400
Received: from [199.232.76.173] (port=40013 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N0gEy-0007P8-2J
	for qemu-devel@nongnu.org; Wed, 21 Oct 2009 14:48:56 -0400
Received: from fg-out-1718.google.com ([72.14.220.155]:51637)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1N0gEx-0002lX-CT
	for qemu-devel@nongnu.org; Wed, 21 Oct 2009 14:48:55 -0400
Received: by fg-out-1718.google.com with SMTP id d23so2997649fga.10
	for <qemu-devel@nongnu.org>; Wed, 21 Oct 2009 11:48:53 -0700 (PDT)
Message-ID: <4ADF5790.8000603@codemonkey.ws>
Date: Wed, 21 Oct 2009 13:48:48 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1256117106-9475-1-git-send-email-agraf@suse.de>	<1256117106-9475-2-git-send-email-agraf@suse.de>	<4ADF1AE4.8020004@codemonkey.ws>	<EAD4B0F9-3F0D-4670-AD78-80FE83192FA6@suse.de>	<4ADF3CB5.9090700@codemonkey.ws>	<80C7ACF1-A6F3-4212-8AFB-E97C23C98218@suse.de>
	<4ADF4DAA.1030501@codemonkey.ws> <4ADF5600.2070500@redhat.com>
In-Reply-To: <4ADF5600.2070500@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 1/9] Export function for VA defined ram
	allocation
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>, Alexander Graf <agraf@suse.de>, qemu-devel <qemu-devel@nongnu.org>

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