From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL1ln-0005US-FC for qemu-devel@nongnu.org; Sun, 17 Jan 2016 23:50:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL1lk-0006Yo-8C for qemu-devel@nongnu.org; Sun, 17 Jan 2016 23:50:23 -0500 Date: Mon, 18 Jan 2016 15:42:04 +1100 From: David Gibson Message-ID: <20160118044204.GK9301@voom.fritz.box> References: <1452859244-9500-1-git-send-email-david@gibson.dropbear.id.au> <1452859244-9500-4-git-send-email-david@gibson.dropbear.id.au> <569C5170.9000606@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eMP3JyRexyk9c0Bv" Content-Disposition: inline In-Reply-To: <569C5170.9000606@ozlabs.ru> Subject: Re: [Qemu-devel] [PATCH 03/10] pseries: Clean up hash page table allocation error handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, armbru@redhat.com, mdroth@linux.vnet.ibm.com --eMP3JyRexyk9c0Bv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 18, 2016 at 01:44:00PM +1100, Alexey Kardashevskiy wrote: > On 01/15/2016 11:00 PM, David Gibson wrote: > >The spapr_alloc_htab() and spapr_reset_htab() functions currently handle > >all errors with error_setg(&error_abort, ...). > > > >But really, the callers are really better placed to decide on the error > >handling. So, instead make the functions use the error propagation > >infrastructure. > > > >In the callers we change to &error_fatal instead of &error_abort, since > >this can be triggered by a bad configuration or kernel error rather than > >indicating a programming error in qemu. > > > >While we're at it improve the messages themselves a bit, and clean up the > >indentation a little. > > > >Signed-off-by: David Gibson > >--- > > hw/ppc/spapr.c | 24 ++++++++++++++++-------- > > 1 file changed, 16 insertions(+), 8 deletions(-) > > > >diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > >index b7fd09a..d28e349 100644 > >--- a/hw/ppc/spapr.c > >+++ b/hw/ppc/spapr.c > >@@ -1016,7 +1016,7 @@ static void emulate_spapr_hypercall(PowerPCCPU *cp= u) > > #define CLEAN_HPTE(_hpte) ((*(uint64_t *)(_hpte)) &=3D tswap64(~HPTE6= 4_V_HPTE_DIRTY)) > > #define DIRTY_HPTE(_hpte) ((*(uint64_t *)(_hpte)) |=3D tswap64(HPTE64= _V_HPTE_DIRTY)) > > > >-static void spapr_alloc_htab(sPAPRMachineState *spapr) > >+static void spapr_alloc_htab(sPAPRMachineState *spapr, Error **errp) > > { > > long shift; > > int index; > >@@ -1031,7 +1031,8 @@ static void spapr_alloc_htab(sPAPRMachineState *sp= apr) > > * For HV KVM, host kernel will return -ENOMEM when requested > > * HTAB size can't be allocated. > > */ > >- error_setg(&error_abort, "Failed to allocate HTAB of requested = size, try with smaller maxmem"); > >+ error_setg_errno(errp, -shift, > >+ "Error allocating KVM hash page table, try sma= ller maxmem"); > > } else if (shift > 0) { > > /* > > * Kernel handles htab, we don't need to allocate one > >@@ -1040,7 +1041,10 @@ static void spapr_alloc_htab(sPAPRMachineState *s= papr) > > * but we don't allow booting of such guests. > > */ > > if (shift !=3D spapr->htab_shift) { > >- error_setg(&error_abort, "Failed to allocate HTAB of reques= ted size, try with smaller maxmem"); > >+ error_setg(errp, > >+ "Small allocation for KVM hash page table (%ld < %" > >+ PRIu32 "), try smaller maxmem", >=20 >=20 >=20 > Even though it is not in the CODING_STYLE, I have not seen anyone objecti= ng > the very good kernel's "never break user-visible strings" rule or rejecti= ng > patches with user-visible strings failing to fit 80 chars limit. I'm not. Or rather, the string is already broken by the PRIu32, so the newline doesn't make it any less greppable. --=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 --eMP3JyRexyk9c0Bv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWnG0cAAoJEGw4ysog2bOSn/YQANVG/L4sqOIzo4KwAnpsoJ5E u79MwkS982nd9+GGxYhfjlksdlAs5ty/I5gJXzCgpM1JT9H4tn3TNPCvIWOR8Eoq zX31EEZ/PprKQVjjbNhiLpzTRaAkXj55FcLXDoKIp3gSeBeT4xZ2JuXHPkD4rF/Z jogtkStLbltjo23f0Ox30MVTUj8m3nQdnjvx49AnTxM01Olutbkz8+w63YMQpOEd 573hLHQvuU7NlcZnWyQQhMp7JIhuwrhCL83/ScKP3oq3MjbOdAw4UkVIGkDt973p A8/ssAUyjGH+B6ja+t32FeIsPqd9FAUTLdszJ3DwhufS5cG5JMdByPHEkQh6GIS8 q9btZQaMtPgilY3JVbxQfAh5QDgMvTFuuRbbJZAPqSlKG467yOYD+lD3xNyyJkan Q/ms20N/PAdDBAVmS2+JEsKiACjHrl9I0SRCh8W0M68E3w9Cr8VJqZEmWLEMKojb ECsDOeOqQ2ey+NenYYUCTUgmqf3Mp3bnRvR46n7YjC/zSlJdVpY3P5q/ZCFgZ0kx NoCITCPFC9k+Oy8rT4HMXQDRkhmzLWKiUr4cR09V/WV1kj6sA2tLZF+j8FY8iwZZ CsB0TPZwwKFad7S14oFLZOXu86lvfvZgIfYeQekI++URQNkS4kaetlYpxsn2rzTJ fsPFXrVVIQuTk4QK695x =rhlF -----END PGP SIGNATURE----- --eMP3JyRexyk9c0Bv--