From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLKN6-0000LS-FV for qemu-devel@nongnu.org; Mon, 18 Jan 2016 19:42:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLKN5-0003k9-6w for qemu-devel@nongnu.org; Mon, 18 Jan 2016 19:42:08 -0500 Date: Tue, 19 Jan 2016 11:20:58 +1100 From: David Gibson Message-ID: <20160119002058.GQ9301@voom.fritz.box> References: <1453091083-13931-1-git-send-email-david@gibson.dropbear.id.au> <1453091083-13931-4-git-send-email-david@gibson.dropbear.id.au> <569CA6BF.9060606@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lt3WynA+XK9Fj6D4" Content-Disposition: inline In-Reply-To: <569CA6BF.9060606@redhat.com> Subject: Re: [Qemu-devel] [PATCHv3 3/9] pseries: Clean up hash page table allocation error handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: lvivier@redhat.com, aik@ozlabs.ru, armbru@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, qemu-ppc@nongnu.org --lt3WynA+XK9Fj6D4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 18, 2016 at 09:47:59AM +0100, Thomas Huth wrote: > On 18.01.2016 05:24, David Gibson wrote: > > The spapr_alloc_htab() and spapr_reset_htab() functions currently handle > > all errors with error_setg(&error_abort, ...). > >=20 > > But really, the callers are really better placed to decide on the error > > handling. So, instead make the functions use the error propagation > > infrastructure. > >=20 > > 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. > >=20 > > While we're at it improve the messages themselves a bit, and clean up t= he > > indentation a little. > >=20 > > Signed-off-by: David Gibson > > --- > > hw/ppc/spapr.c | 24 ++++++++++++++++-------- > > 1 file changed, 16 insertions(+), 8 deletions(-) > >=20 > > 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 *c= pu) > > #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)) > > =20 > > -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 *s= papr) > > * 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 sm= aller 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 *= spapr) > > * but we don't allow booting of such guests. > > */ > > if (shift !=3D spapr->htab_shift) { > > - error_setg(&error_abort, "Failed to allocate HTAB of reque= sted size, try with smaller maxmem"); > > + error_setg(errp, > > + "Small allocation for KVM hash page table (%ld < %" > > + PRIu32 "), try smaller maxmem", > > + shift, spapr->htab_shift); >=20 > Maybe you should add an "return" statement here - theoretically you do > not want to continue with "kvmppc_kern_htab =3D true" in case of errors. > (practically this does not happen because errp =3D error_fatal, but in > case the caller gets changed, this might introduce subtle errors > otherwise) No, actually. If the error is non-fatal, then we *must* set kvmppc_kern_htab =3D true. It is possible we can continue without the size of hash table we wanted - we did so until pretty recently. But it *is* still a kernel provided hash table, and must be marked as such to operate correctly. >=20 > > } > > =20 > > spapr->htab_shift =3D shift; > > @@ -1064,17 +1068,21 @@ static void spapr_alloc_htab(sPAPRMachineState = *spapr) > > * If host kernel has allocated HTAB, KVM_PPC_ALLOCATE_HTAB ioctl is > > * used to clear HTAB. Otherwise QEMU-allocated HTAB is cleared manual= ly. > > */ > > -static void spapr_reset_htab(sPAPRMachineState *spapr) > > +static void spapr_reset_htab(sPAPRMachineState *spapr, Error **errp) > > { > > long shift; > > int index; > > =20 > > shift =3D kvmppc_reset_htab(spapr->htab_shift); > > if (shift < 0) { > > - error_setg(&error_abort, "Failed to reset HTAB"); > > + error_setg_errno(errp, -shift, > > + "Error resetting KVM hash page table, try smaller m= axmem"); >=20 > dito, better do an "return" here... No. The remaining statement in the function could be relevant if we're somehow able to keep going here. > > } else if (shift > 0) { > > if (shift !=3D spapr->htab_shift) { > > - error_setg(&error_abort, "Requested HTAB allocation failed= during reset"); > > + error_setg(errp, > > + "Reduced size on reset of KVM hash page table (%ld < %" > > + PRIu32 "), try smaller maxmem", > > + shift, spapr->htab_shift); >=20 > ... and here. Hrm.. here, yes we would be in trouble, but 'return' wouldn't help in the slightest. Instead we'd need to change spapr->htab_shift to have any hope of continuing. I'll make that change. --=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 --lt3WynA+XK9Fj6D4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWnYFqAAoJEGw4ysog2bOSyWMP/0O5fv5nFKhdWi2Mqsasib3a spMRK9bdz2bRFKA0IgENeH7KsImS4dnpaoFCS1qyIyqYHKMTcFtn2JleUvieMQwP 0tU0gZ1gBAjfgGS9WF/GwFtmj5SYcs9mK7ND0xPl5hQa4Mezr/S2Kbn/kCXkR/U6 KW6JIArphzEhrf6UWBGOmbRs8DQEA/5m9XQG5Rq8DZWnK6KGIPZy1mqAUr3BHsZ0 0clIk1bkRJBqo56c3Ck2QI2XZEWrg1MUCLUVa2QKwLZ+VXsgpQjkA9W6/McRKhju 1007bArbcZcQICO9ywuBLt8uLvPRMt9e5ne2jccOl68JCqcBd2ePCWumv0Cb/CQb o41yTQ6nnd0F8XsSMRWJMfMdcjVGLFRAjAshAud4rV/Z3mX8YKBX5wxeqSncYKCw QSsk3kGyVr9pfl0Ho73Kga3uz4TBeH0KKfdRL1LoQ4ciCaN242+HHcf0dGISiPx8 FBcz3zDRaAq5vZ3yzfr9InwNADwmPbKy7QSDjyssr5IAMOcsMq72QdtzoiwOqXCJ QXT1xtraZcTTHO9fsF28d2VGcOTydcg9WWadyzktPK/PSqD79tHsAPbMXFcZyG1g TkzpmxqUEThnis5O/xhINODRPzoJaIF4DeoHW7or1NfoHGqdoILT+biidr7opJbB ytlyST6AeqQWucQSCi15 =Hfl4 -----END PGP SIGNATURE----- --lt3WynA+XK9Fj6D4--