[Skiboot] [PATCH] xive: fix return value of opal_xive_allocate_irq()

[Cédric Le Goater]

When the maximum number of interrupts per chip is reached,
xive_try_allocate_irq() returns an internal XIVE error:
XIVE_ALLOC_NO_SPACE. But its value 0xffffffff is interpreted as a
positive value by its caller opal_xive_allocate_irq() and not as an
error.

opal_xive_allocate_irq() returns this value to Linux which also
considers 0xffffffff as a valid interrupt number and tries to get the
interrupt characteritics using opal_xive_get_irq_info(). This OPAL
calls finally fails leading to all sort of errors on the host which is
not prepared for such a scenario. Code impacted are the IPI setup and
the both XIVE KVM devices.

Fix by returning OPAL_RESOURCE from xive_try_allocate_irq() which is
consistent with the other errors returned by this routine. This fixes
the behavior in opal_xive_allocate_irq() and in Linux.

A workaround could be introduced in Linux to consider 0xffffffff as a
OPAL_RESOURCE value. This assumption is valid with the current XIVE
IRQ number encoding.

Reported-by: Greg Kurz <groug at kaod.org>
Signed-off-by: Cédric Le Goater <clg at kaod.org>
---
 hw/xive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xive.c b/hw/xive.c
index 76b41a9ee95f..5dc66598ee12 100644
--- a/hw/xive.c
+++ b/hw/xive.c
@@ -5059,7 +5059,7 @@ static int64_t xive_try_allocate_irq(struct xive *x)
 	idx = bitmap_find_zero_bit(*x->ipi_alloc_map, base_idx, max_count);
 	if (idx < 0) {
 		unlock(&x->lock);
-		return XIVE_ALLOC_NO_SPACE;
+		return OPAL_RESOURCE;
 	}
 	bitmap_set_bit(*x->ipi_alloc_map, idx);
 	girq = x->int_base + idx;
-- 
2.21.0