From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O6nR5-0005nN-RI
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:14:59 -0400
Received: from [140.186.70.92] (port=47210 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O6nR3-0005ml-Pm
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:14:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <mtosatti@redhat.com>) id 1O6nQy-0000Op-5f
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:14:53 -0400
Received: from mx1.redhat.com ([209.132.183.28]:41703)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <mtosatti@redhat.com>) id 1O6nQx-0000Of-Ua
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:14:52 -0400
Date: Tue, 27 Apr 2010 11:50:20 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20100427145020.GD23249@amt.cnet>
References: <cover.1272304746.git.mtosatti@redhat.com>
	<2e085c19aac78e6c4335eac4fffeb5cfca4bbb26.1272304746.git.mtosatti@redhat.com>
	<p2g8286e4ee1004270732m5ddf6a74m81d18c149ed01ecd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <p2g8286e4ee1004270732m5ddf6a74m81d18c149ed01ecd@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] Re: [PATCH 10/10] introduce qemu_ram_map
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: Cam Macdonell <cam@cs.ualberta.ca>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org

On Tue, Apr 27, 2010 at 08:32:27AM -0600, Cam Macdonell wrote:
> >
> > +ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
> > +{
> > + =A0 =A0RAMBlock *new_block;
> > +
> > + =A0 =A0size =3D TARGET_PAGE_ALIGN(size);
> > + =A0 =A0new_block =3D qemu_malloc(sizeof(*new_block));
> > +
> > + =A0 =A0new_block->host =3D host;
> > +
> > + =A0 =A0new_block->offset =3D last_ram_offset;
> > + =A0 =A0new_block->length =3D size;
> > +
> > + =A0 =A0new_block->next =3D ram_blocks;
> > + =A0 =A0ram_blocks =3D new_block;
> > +
> > + =A0 =A0phys_ram_dirty =3D qemu_realloc(phys_ram_dirty,
> > + =A0 =A0 =A0 =A0(last_ram_offset + size) >> TARGET_PAGE_BITS);
> > + =A0 =A0memset(phys_ram_dirty + (last_ram_offset >> TARGET_PAGE_BITS=
),
> > + =A0 =A0 =A0 =A0 =A0 0xff, size >> TARGET_PAGE_BITS);
> > +
> > + =A0 =A0last_ram_offset +=3D size;
> > +
> > + =A0 =A0if (kvm_enabled())
> > + =A0 =A0 =A0 =A0kvm_setup_guest_memory(new_block->host, size);
> > +
> > + =A0 =A0return new_block->offset;
> > +}
> > +
> > =A0ram_addr_t qemu_ram_alloc(ram_addr_t size)
> > =A0{
> > =A0 =A0 RAMBlock *new_block;
> > --
> > 1.6.6.1
> >
>=20
> Sorry for being late to reply, is there a strong reason not to have
> the function handle the mmap itself?  As As Anthony points out, that
> way we don't have worry about realloc changing the pointer in the
> function.

The caller might want a different protection for the memory map.