From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 10/10] introduce qemu_ram_map
Date: Tue, 27 Apr 2010 11:50:20 -0300
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-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org,
	kvm@vger.kernel.org
To: Cam Macdonell <cam@cs.ualberta.ca>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:53886 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756144Ab0D0QOx (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 27 Apr 2010 12:14:53 -0400
Content-Disposition: inline
In-Reply-To: <p2g8286e4ee1004270732m5ddf6a74m81d18c149ed01ecd@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <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_BI=
TS),
> > + =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.