From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwA4r-0001ps-ET for qemu-devel@nongnu.org; Tue, 10 Nov 2015 09:39:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwA4n-0004E5-VR for qemu-devel@nongnu.org; Tue, 10 Nov 2015 09:39:17 -0500 Received: from e17.ny.us.ibm.com ([129.33.205.207]:41570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwA4n-0004Cy-RF for qemu-devel@nongnu.org; Tue, 10 Nov 2015 09:39:13 -0500 Received: from localhost by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Nov 2015 09:39:11 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: <1447133094-32676-3-git-send-email-bharata@linux.vnet.ibm.com> References: <1447133094-32676-1-git-send-email-bharata@linux.vnet.ibm.com> <1447133094-32676-3-git-send-email-bharata@linux.vnet.ibm.com> Message-ID: <20151110143857.25378.51227@loki> Date: Tue, 10 Nov 2015 08:38:57 -0600 Subject: Re: [Qemu-devel] [PATCH v1 2/2] spapr: Handle failure of KVM_PPC_ALLOCATE_HTAB ioctl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, david@gibson.dropbear.id.au Quoting Bharata B Rao (2015-11-09 23:24:54) > KVM_PPC_ALLOCATE_HTAB ioctl can return -ENOMEM for KVM guests and QEMU > never handled this correctly. But this didn't cause any problems till > now as KVM_PPC_ALLOCATE_HTAB ioctl returned with smaller than requested > HTAB when enough contiguous memory wasn't available in the host. > After the proposed kernel change: https://patchwork.ozlabs.org/patch/5305= 01/, > KVM_PPC_ALLOCATE_HTAB ioctl will not fallback to lower sized HTAB > allocation and will fail if requested HTAB size can't be met. > = > Check for such failures in QEMU and abort appropriately. This will > prevent guest kernel from hanging/freezing during early boot by doing > graceful exit when host is unable to allocate requested HTAB. > = > Signed-off-by: Bharata B Rao > --- > hw/ppc/spapr.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > = > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index e1202ce..a64a1b5 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -1021,9 +1021,19 @@ static void spapr_alloc_htab(sPAPRMachineState *sp= apr) > * RAM */ > = > shift =3D kvmppc_reset_htab(spapr->htab_shift); > - > - if (shift > 0) { > - /* Kernel handles htab, we don't need to allocate one */ > + if (shift < 0) { > + /* > + * 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 s= ize, try with smaller maxmem"); Wording is appropriate, but maybe just "Failed to allocate HTAB, try with smaller maxmem" to distinguish it from the error below where the call succe= eds but there's a size mismatch? > + } else if (shift > 0) { > + /* > + * Kernel handles htab, we don't need to allocate one > + * > + * Older kernels can fall back to lower HTAB shift values, > + * but we don't allow booting of such guests. > + */ > if (shift !=3D spapr->htab_shift) { > error_setg(&error_abort, "Failed to allocate HTAB of request= ed size, try with smaller maxmem"); > } > @@ -1055,7 +1065,9 @@ static void spapr_reset_htab(sPAPRMachineState *spa= pr) > int index; > = > shift =3D kvmppc_reset_htab(spapr->htab_shift); > - if (shift > 0) { > + if (shift < 0) { > + error_setg(&error_abort, "Failed to reset HTAB"); > + } else if (shift > 0) { > if (shift !=3D spapr->htab_shift) { > error_setg(&error_abort, "Requested HTAB allocation failed d= uring reset"); > } > -- = > 2.1.0 >=20