From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] hw/intc: fix failure return for xics_alloc_block()
Date: Wed, 24 Feb 2016 11:36:49 +1100 [thread overview]
Message-ID: <20160224003649.GA2808@voom.fritz.box> (raw)
In-Reply-To: <20160223184644.39a9df6f@bahia.huguette.org>
[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]
On Tue, Feb 23, 2016 at 06:46:44PM +0100, Greg Kurz wrote:
> On Wed, 10 Feb 2016 10:41:16 +0100
> Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
>
> > On Mon, 8 Feb 2016 09:31:49 +0100
> > Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> >
> > > On Mon, 8 Feb 2016 11:45:19 +1000
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > On Fri, Feb 05, 2016 at 09:43:40AM +0100, Greg Kurz wrote:
> > > > > From: Brian W. Hart <hartb@linux.vnet.ibm.com>
> > > > >
> > > > > xics_alloc_block() does not return a clear error code when it
> > > > > fails to allocate a block of interrupts. Instead it returns the
> > > > > base interrupt number minus 1. This change updates it to return a
> > > > > clear -1 in case of failure (following the example of xics_alloc()).
> > > > >
> > > > > The two callers of xics_alloc_block() are updated to check for
> > > > > a negative return as an error. They had previously checked for
> > > > > a 0 return as an error, which wrongly treated most failures as
> > > > > successes.
> > > > >
> > > > > Fixes: bee763dbfb8cfceea112131970da07f215f293a6
> > > > > Signed-off-by: Brian W. Hart <hartb@linux.vnet.ibm.com>
> > > > > [only pass src and num to trace_xics_alloc_block_failed_no_left,
> > > > > added trace_xics_alloc_block_failed_no_left definition to trace-events]
> > > > > Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
> > > >
> > > > Hrm, it would probably be better to give xics_alloc_block() an Error
> > > > ** argument so it can report errors using the new API.
> > > >
> > >
> > > Sure. I can rework the patch to do so.
> > >
> >
> > The trace_xics_alloc_block_failed_no_left trace is more a debugging thing
> > than an error to be reported to the user. Also, rtas_ibm_change_msi()
> > already has a meaningful error message:
> >
> > error_report("Cannot allocate MSIs for device %x", config_addr);
> >
> > So in the end, I'm not sure about the benefit of passing an Error **
> > down to xics_alloc_block().
> >
>
> Hi David !
>
> Given the remarks above, do you still think we should pass Error ** ?
I still think using the Error API would be preferable, but it doesn't
make a huge difference.
> > > > TBH the whole xics_alloc_block() interface is kind of dubious, or at
> > > > least the ics_find_free_block() part of it. Dynamically allocating
> > > > irqs to devices is basically awful for migration, so it's better to
> > > > have fixed allocations of all interrupts at the machine level.
> > > >
> > >
> > > I agree about the extra complexity, but isn't it the purpose of
> > > the ibm,change-msi RTAS call ? I'm not sure to understand what you
> > > are suggesting...
> > >
> >
> > And anyway, even if the decision is made one day to have fixed
> > allocations, shouldn't we consider fixing this bug first ?
> >
>
> According to the following commit changelog, the dynamic allocation was
> introduced to support PCI hot(un)plug. Maybe Alexey may explain why it
> got coded this way.
>
> commit bee763dbfb8cfceea112131970da07f215f293a6
> Author: Alexey Kardashevskiy <aik@ozlabs.ru>
> Date: Fri May 30 19:34:15 2014 +1000
>
> spapr: Move interrupt allocator to xics
>
> I'm not sure of the amount of reflexion and work needed to address your
> concern... Given the time frame, what about deferring xics rework to 2.7
> and fix the bug we currently have in 2.6 ?
Yeah, sorry, I realised after I sent that the allocation does
actually make sense in this case - these are guest triggered
allocations that we really do need an allocator for, not host setup
allocations which we have used in the past but turned out to be
dubious.
--
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-02-24 2:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 8:43 [Qemu-devel] [PATCH] hw/intc: fix failure return for xics_alloc_block() Greg Kurz
2016-02-08 1:45 ` David Gibson
2016-02-08 8:31 ` Greg Kurz
2016-02-10 9:41 ` Greg Kurz
2016-02-23 17:46 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2016-02-23 20:24 ` Greg Kurz
2016-02-24 0:36 ` David Gibson [this message]
2016-02-24 20:22 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160224003649.GA2808@voom.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=gkurz@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).