On Wed, 24 Feb 2016 11:36:49 +1100 David Gibson <da...@gibson.dropbear.id.au> wrote:
> On Tue, Feb 23, 2016 at 06:46:44PM +0100, Greg Kurz wrote: > > On Wed, 10 Feb 2016 10:41:16 +0100 > > Greg Kurz <gk...@linux.vnet.ibm.com> wrote: > > > > > On Mon, 8 Feb 2016 09:31:49 +0100 > > > Greg Kurz <gk...@linux.vnet.ibm.com> wrote: > > > > > > > On Mon, 8 Feb 2016 11:45:19 +1000 > > > > David Gibson <da...@gibson.dropbear.id.au> wrote: > > > > > > > > > On Fri, Feb 05, 2016 at 09:43:40AM +0100, Greg Kurz wrote: > > > > > > From: Brian W. Hart <ha...@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 <ha...@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 <gk...@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 <a...@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. > There are other issues related to xics actually. I'll post a series with all the fixes. Cheers. -- Greg