qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 03/10] pseries: Clean up hash page ta


From: David Gibson
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 03/10] pseries: Clean up hash page table allocation error handling
Date: Mon, 18 Jan 2016 15:42:04 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

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 <address@hidden>
> >---
> >  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.

I'm not.  Or rather, the string is already broken by the PRIu32, so
the newline doesn't make it any less greppable.

-- 
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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]