From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr7o8-0007t5-0l for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:08:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr7o3-0002Qf-71 for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:08:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr7o2-0002QU-US for qemu-devel@nongnu.org; Wed, 19 Nov 2014 11:08:35 -0500 Date: Wed, 19 Nov 2014 16:08:30 +0000 From: Stefan Hajnoczi Message-ID: <20141119160830.GF16593@stefanha-thinkpad.redhat.com> References: <1416254843-16859-1-git-send-email-mst@redhat.com> <1416254843-16859-3-git-send-email-mst@redhat.com> <87a93nmggx.fsf@elfo.elfo> <8761ebmfza.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CXFpZVxO6m2Ol4tQ" Content-Disposition: inline In-Reply-To: <8761ebmfza.fsf@elfo.elfo> Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Peter Maydell , Paolo Bonzini , QEMU Developers , "Dr. David Alan Gilbert" , "Michael S. Tsirkin" --CXFpZVxO6m2Ol4tQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2014 at 03:18:01PM +0100, Juan Quintela wrote: > Peter Maydell wrote: > > On 19 November 2014 14:07, Juan Quintela wrote: > >> My understanding is that it is a "trick". We have internal memory for= a > >> device that is needed for the emulation, but not showed to the guest. > >> And it is big enough that we want to save it during the "live" stage of > >> migration, so we mark it as RAM. if it is somekind of cash, we can ju= st > >> enlarge it on destination, and it don't matter. If this has anything > >> different on the other part of the RAM, we are on trouble. > > > > Would it be feasible to just have the migration code provide > > an API for registering things to be migrated in the live > > migration stage, rather than creating memory regions which > > you can't actually use for most of the purposes the memory > > region API exists for? >=20 > If somebody told me what they need, we can do it. >=20 > Stefan, you needed something like that for data-plane? Or that memory > is mapped on the guest? No, dataplane has no special requirements here. I am working on making the dirty memory bitmap atomic so that dataplane threads can dirty memory at the same time as other threads. But that's a different topic from what you are discussing here. Stefan --CXFpZVxO6m2Ol4tQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUbMB+AAoJEJykq7OBq3PIfQgH/3jywjc0y11c7RxJuNdpMaVe gxeeGRZlKSBAZTrsJAdiC8YEpdi3+YfilBhDkTBoaPArgGImu2enaL2tiRMk5uHY iyu6cRd8rghRQ4QeLGGMsy1Gkjd0kjjlY95itPp/6BqZ1TesueMcr9tGL0jn1JMM bj0OGum8Sj1Ar2KPqyJ0ejxuMkkho+iyZFD0Eu0C3Y82VFgN0gAsR7OWUjHMplCl 0h2uBSE3OuwHELd/YN4MjqOOKnmYtTFkDRKamQCTGv5yeTzmbENdNkDNnvMKH7vc FSUQV7mb6eDrheoo9JjOe/2ELi72l6mnADss9hCql+AHCmUDL7MbQgDgR5Htbgc= =TwEe -----END PGP SIGNATURE----- --CXFpZVxO6m2Ol4tQ--