From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agKIW-0000mT-LU for qemu-devel@nongnu.org; Wed, 16 Mar 2016 18:52:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agKIU-0005t6-Ku for qemu-devel@nongnu.org; Wed, 16 Mar 2016 18:52:12 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:51101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agKIR-0005p5-TM for qemu-devel@nongnu.org; Wed, 16 Mar 2016 18:52:10 -0400 Date: Thu, 17 Mar 2016 09:32:42 +1100 From: David Gibson Message-ID: <20160316223242.GI9032@voom> References: <1458011856-44711-1-git-send-email-aik@ozlabs.ru> <20160315120103.GA11728@work-vm> <20160316003725.GN9032@voom> <20160316090758.GA2246@work-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LmeqhziFqEm+Ep0k" Content-Disposition: inline In-Reply-To: <20160316090758.GA2246@work-vm> Subject: Re: [Qemu-devel] [PATCH qemu] vmstate: Define VARRAY with VMS_ALLOC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Alexey Kardashevskiy , qemu-devel@nongnu.org, Juan Quintela --LmeqhziFqEm+Ep0k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 09:07:59AM +0000, Dr. David Alan Gilbert wrote: > * David Gibson (david@gibson.dropbear.id.au) wrote: > > On Tue, Mar 15, 2016 at 12:01:04PM +0000, Dr. David Alan Gilbert wrote: > > > * Alexey Kardashevskiy (aik@ozlabs.ru) wrote: > > > > This allows dynamic allocation for migrating arrays. > > > >=20 > > > > Already existing VMSTATE_VARRAY_UINT32 requires an array to be > > > > pre-allocated, however there are cases when the size is not known in > > > > advance and there is no real need to enforce it. > > > >=20 > > > > This defines another variant of VMSTATE_VARRAY_UINT32 with WMS_ALLOC > > > > flag which tells the receiving side to allocate memory for the array > > > > before receiving the data. > > > >=20 > > > > The first user of it is the "pseries" machine (POWER8) with > > > > dynamic DMA windows which existence and size are totally dynamic. > > >=20 > > > You say totally dynamic, how big do they get out of interest? > >=20 > > They're basically used to map all guest RAM. Typically we'd be > > looking at one 64-bit TCE per 64K guest page, so we'd be looking at > > 1/8192th of RAM size. > >=20 > > Since we can in theory have guests in the 1T+ range, that might start > > getting pretty big, so we probably should look at incremental transfer > > of the TCE tables at some point. >=20 > OK, you probably need to bump up MAX_VM_CMD_PACKAGED_SIZE (sysemu.h) > which is an arbitrary size limit for postcopies device data; it's current= ly > 16MB. It's just there to stop anything silly, so just turn it up a bit. >=20 > However, if it is fixed at one 64-bit TCE per guest page, why do you > need to dynamically allocate it during migration load, can't you > statically allocate once you know guests memory size? So, guest memory size is what it will be in practice (with Linux guests), but that's under the guest's control, not ours; at least in theory it can be different. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --LmeqhziFqEm+Ep0k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW6d8KAAoJEGw4ysog2bOSM0UQAI29tf7Z5B4Vs6CyGWrehvfO geiRtckG+cHnbhBRPQIOTzA2Cnz0WcIt2dfZYWaW9BvzclA0BOeMGa+N4MJloQbj f25Ko+6GhijJeXnIVHGiKU9vUICW1Vqfj6asZOpMnWlRiscYpNm1iykAdz3Yi0Or xphQM/sHd/DIAS+bkNnWIjYwUe59vLq6SIeUE3QqqlGS8OZEGllS6VTbjjH9hLkA DQIyzGZSQPfeUQksNfiPx+wiu/esPThGQhTOAX3n3dvnZlVA615pKT3MKp2nmRTv BaL8nRpgmEvumTNjadHkgCUrn0ZZJZC0tuAFX3+oPUkQfIF4zod2D/9dAa2SzeMc TxwKBT1fhtDG/nqqRj/lskd0653LmbCDDGJxs6UrEa/5vqeQekEN4YA7t6EoKEPD p6lG9oNNgJGjz5/FXJTGKiMeT0zZ20GjAU1D2jMvJxnHeK/HmurIoDDrDAIY5vZY nNqfDBn+MFm54czy5PgqI3Et7/Di0vj87g0vu2C7ExtiKLNYdzm+3nfRnRQfdyF6 TdlEUmq3bWRD0IAHRq4xxbpFW917coNAbXK/SeeBzimaFOWhvqRxM5qjqvb1kxR/ zq8A9b/Zq9tLhGwXjQLeipAi0qYhZXOXJjTOzzhkUlUpHBsLtxuEth8fzIL0T2IW 78l6gdSW0/L7QeP20D8h =VCQf -----END PGP SIGNATURE----- --LmeqhziFqEm+Ep0k--