Re: [Qemu-devel] [PATCHv3 3/9] pseries: Clean up hash page table allocation error handling

[David Gibson]

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, ...).
> > 
> > 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",
> > +                shift, spapr->htab_shift);
> 
> Maybe you should add an "return" statement here - theoretically you do
> not want to continue with "kvmppc_kern_htab = true" in case of errors.
> (practically this does not happen because errp = 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 = 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.

> 
> >          }
> >  
> >          spapr->htab_shift = 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 manually.
> >   */
> > -static void spapr_reset_htab(sPAPRMachineState *spapr)
> > +static void spapr_reset_htab(sPAPRMachineState *spapr, Error **errp)
> >  {
> >      long shift;
> >      int index;
> >  
> >      shift = 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 
> > maxmem");
> 
> 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 != 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);
> 
> ... 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.

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

signature.asc
Description: PGP signature