From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aKzne-0001nx-1Q for qemu-devel@nongnu.org; Sun, 17 Jan 2016 21:44:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aKzna-0002Gn-Rf for qemu-devel@nongnu.org; Sun, 17 Jan 2016 21:44:09 -0500 Received: from mail-pf0-x241.google.com ([2607:f8b0:400e:c00::241]:35103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aKzna-0002GS-Kb for qemu-devel@nongnu.org; Sun, 17 Jan 2016 21:44:06 -0500 Received: by mail-pf0-x241.google.com with SMTP id 65so11109700pff.2 for ; Sun, 17 Jan 2016 18:44:06 -0800 (PST) References: <1452859244-9500-1-git-send-email-david@gibson.dropbear.id.au> <1452859244-9500-4-git-send-email-david@gibson.dropbear.id.au> From: Alexey Kardashevskiy Message-ID: <569C5170.9000606@ozlabs.ru> Date: Mon, 18 Jan 2016 13:44:00 +1100 MIME-Version: 1.0 In-Reply-To: <1452859244-9500-4-git-send-email-david@gibson.dropbear.id.au> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit 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: David Gibson , armbru@redhat.com Cc: qemu-ppc@nongnu.org, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org 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 *cpu) > #define CLEAN_HPTE(_hpte) ((*(uint64_t *)(_hpte)) &= tswap64(~HPTE64_V_HPTE_DIRTY)) > #define DIRTY_HPTE(_hpte) ((*(uint64_t *)(_hpte)) |= 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 *spapr) > * 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 smaller 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 != spapr->htab_shift) { > - error_setg(&error_abort, "Failed to allocate HTAB of requested size, try with smaller maxmem"); > + error_setg(errp, > + "Small allocation for KVM hash page table (%ld < %" > + PRIu32 "), try smaller maxmem", Even though it is not in the CODING_STYLE, I have not seen anyone objecting the very good kernel's "never break user-visible strings" rule or rejecting patches with user-visible strings failing to fit 80 chars limit. -- Alexey