From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZL4W8-0007ib-Cp for qemu-devel@nongnu.org; Fri, 31 Jul 2015 03:14:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZL4W7-0004yF-C7 for qemu-devel@nongnu.org; Fri, 31 Jul 2015 03:14:08 -0400 Date: Fri, 31 Jul 2015 17:13:11 +1000 From: David Gibson Message-ID: <20150731071311.GB15727@voom.fritz.box> References: <1438268115-25273-1-git-send-email-bharata@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: <1438268115-25273-1-git-send-email-bharata@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH] spapr: Provide an error message when migration fails due to htab_shift mismatch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: aik@ozlabs.ru, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, agraf@suse.de --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2015 at 08:25:15PM +0530, Bharata B Rao wrote: > Include an error message when migration fails due to mismatch in > htab_shift values at source and target. This should provide a bit more > verbose message in addition to the current migration failure message > that reads like: >=20 > qemu-system-ppc64: error while loading state for instance 0x0 of device '= spapr/htab' >=20 > After this patch, the failure message will look like this: >=20 > qemu-system-ppc64: htab_shift mismatch: source 29 target 24 > qemu-system-ppc64: error while loading state for instance 0x0 of device '= spapr/htab' >=20 > Signed-off-by: Bharata B Rao I've applied this to spapr-next and a new spapr-fix tree (intended for fixes which should go to the current feature-frozen qemu, not just the next one). It's certainly better than the current cryptic failure. Longer term I think we need to work harder to try to get the hash table size the same at both ends though - we should rearrange things so we get the size from the migration stream and then use that to feed the hint to the kernel allocation. Sorry I haven't looked properly yet at the patch you sent which works towards that. --=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 --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVuyAHAAoJEGw4ysog2bOSUPAP/jQ06I1Q5zrC33YTpMyry8+g OpktYVXyiJ3XMRs2StBQfDhGZqYXkWNkYf3IHtYi9Nix1M7nTObgmHzVyDfAGvYl xv02ldl81ZS5qNL+ke8oIV4yqa4+4wYBSU9rWCuz8prw/BUZNjdPz3fLhVYZxPA9 YtnOukAPuJlZeDFj7GJHwdAMAWzUcYgTWBGDqKVaIMttt4Z1Nuhk3IAQkISKwtdC aqLXo25ZRG39+amC74g2TUN6lovx4dIHvas9BDO5CvaXq+kTDVeaQQ8ay5eatSgh x1+CtaKeLnGlTUPDuRmqJOXQIkT4tqlvKucQ4Gl9WvwN6WDQZq++JQ77h2osFgXZ ohO4uU0w3tw+JaDk85g1qUJufZ5dN8t4woQa3KgC7+Rh+ldpkj5mjtS9svVARFjV pIizOhaW4Y2IT/UrkoedloD7iiIdZRGZp9bcl+St6K5e9bBkMaHvvkrUFOxD0gEd IULpkZu2ydK9zvPnJ8cVvsvHG/WksJvL+/AOSc5KOzeXmhI1StpTLpxVQHHUzJDc Dky18sV9wPGKYmuunjnafLlSZQmVDcZ3Iqbkhjzgnrph7i1PQwMg9ukBa9GO7ILQ KxtTRF7qOsNqePINxwgP8G4MNIm/b1cJP0bZZjTr4CDAtZDDeq+2ZMkjWyvj7p84 0NCBURdkernMko8J9NHv =p+Nz -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi--